Re: Icons of program

[Dwight Hubbard <dlhubbar collins rockwell com>]

Miroslav Silovic wrote:

> Andreas Kostyrka <andreas@rainbow.studorg.tuwien.ac.at> writes:
>
> > Actually we are talking here not about a global config registry, but
> > more something like a per-file registry.
>
> I was actually talking specifically about windows registry. Now let's
> take a cut into GNOME:
>
> Okay, the list mentioned the four distinct ways to handle per-file
> info:
>
> 1) single, big file somewhere in the user's home directory
> 2) single, big system-wide file (handled with a daemon)
> 3) small files in a separate tree in the user's home directory
> 4) small files in the same dir as the files they affect
>
> Advantages and disadvantages (IMO):
>
> 1)
>
> + low inode cost
> - won't cooperate with the existing UNIX tools (cp, mv, etc)
> - needs separate mechanism to handle permissions (as permissions of the
>   file won't necessarily match permissions of its meta attributes)
> - other users won't get meta data of the same file

- Difficult to extract data for one file when moving to another system or
removable media.  This also means that metainfo on removable media from
other systems will not be present.
- File corruption will affect all file's metainfo.

>
>
> 2)
>
> + low inode cost
> + this system can migrate to kernel
> + users can share meta-data, even remote users
> - won't cooperate with the existing UNIX tools
> - won't work with removable devices (CDs, floppies) without extra work
> - needs admin access to run daemon (not suitable in multi-user
>   environment where users compile GNOME for personal use) - this is
>   marginal disadvantage

- Difficult to extract data for one file when moving to another system or
removable media.  This also means that metainfo on removable media from
other systems will not be present.- File corruption will affect all file's
metainfo.  On bigger systems, there is a likelihood that with this setup
the metainfo and the files would be on different filesystem/drives.  A bad
hard drive could loose all metainfo on the system even though the files
are there.

>
>
> This system is actually the closest we can get to having the metadata
> implemented on the FS level - provided that removable media get their
> own db.
>
> 3)
>
> Same as 1), but at high inode cost. This looks like a bad idea to me.

Not the same as 1)+ Corruption of one files metainfo will not affect other
files metainfo.

>
>
> 4)
>
> + works passably well with existing tools
> + works well with mounted filesystems and removable media
> + simple to implement
> + users can easily share metadata
> - high inode cost
> - 'ls' gives litter
>

+Corruption of one files metainfo will not affect other files metainfo.

> Well, that's it. I like 4) and 2) - and am sort of undecided between
> these two. 4) looks least bad (as its disadvantages are mostly
> aesthetic). Flame on. :)

I personally like 4.  Although, it is a bit annoying to have the .info
files together with the file.  It has several  advantages as well, the
biggest one is it is very difficult to screw up all your info files.  I
think it would be beneficial to have the system have a central repository
of default .info files that get used for files based on their magic if the
file doesn't have a .info file for it.  That way the .info files would
only be needed to override the default.

In addition, it would really be nice to have multiple simple vfs
implementations that implement solutions 1, 3 and 4.  That way the user
can decide on how metainfo is handled.