Re: My thoughts on icons and meta-data

[Mark Andrew Hulme-Jones <ceemahj cee hw ac uk>]

On Mon, 27 Apr 1998, Dale Pontius wrote:

> Mark Andrew Hulme-Jones wrote:
> 
> > I was however left thinking when the idea of using the Berkely DB
> > system. At first I thought that leaving the user with a binary file
> > (rather than one they could edit with a text editor) was a poor idea,
> > but the more I consider it, the more I like the idea.  It appeals mainly
> > because it means one large file in the users .gnome directory (or
> 
> Does this handle the situation where some file manipulation is done
> via the file manager, and some is done via the command line? I can 
> see a .info file getting badly out of sync if things are done at the
> command line instead of using the file manager. (particularly 'mv')
No, doing things with the command line would mean that the database would
get out of sync with the filesystem. Note that there is a huge advantage
here of a database rather than .info files, given that should this
out-of-syncness actually happen, it's far easier for the filemanager to
compare the contents of a database with the actual filing system and
delete/add entries accordingly, with .info files, you have to find the
.info files first and even then you don't know what file on the filing
system that they _used_ to correspond to, so you have virtually no idea
what to do with them.

Of course the other advantage I can see is speed, (the KDE appears to have
a severe problem with this - ie. when I look at a directory with 100 or so
icons in it I have to wait a considerable length of time for it to be
displayed, personally I'd rather the Gnome fm didn't exhibit such
behavior... Of course this may be a problem with image-caching, but who
knows.) a db file would allow a reasonably efficient random access search
through its contents, as opposed to having to read in the contents of 100+
.info files in a worst case scenario.

> 
> Not that Extended Attributes under OS/2 don't have their problems,
> some common practices can break them. But they're more robust than
> a ..info file. I don't know how the Mac resource fork compares.
> 
> Dale Pontius
> edgehp@together.net
> 


Mark