Re: Icons of program

[Miroslav Silovic <silovic zesoi fer hr>]

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

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

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.

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

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 refuse to use .sig