Re: Icons of program

[Toshio Kuratomi <badger prtr-13 ucsc edu>]

On Wed, 22 Apr, 1998 at 01:25:00PM +0200, Miroslav Silovic set free these words:
> 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:
> 
This is not quite true: I don't think anyone's proposed anything in the user's
home directory that did not also have a centralized service (Either a system
wide "big file" or a system wide parallel tree.)  Also -- #2 should really be
system-wide database [no system wide big file required a daemon.]

> 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)
  * Correction: The only place where this is going to matter is where the user
    doesn't give himself read permissions on files he creates... (The
    meta-info in a user's directory is essentially a user's own customization,
    so no one but the user needs to read it.)
> - other users won't get meta data of the same file
  * This is also misleading -- Other user's won't get the same meta-data of
    the same file.  There are still the system wide defaults.  If you mean the
    user may want to send their metadata along with the file, you are
    partially correct -- there is no way to send file specific metadata
    without extracting the information from the "one big file" manually.
    (Although this could be done with a text editor or a tool written for the
    purpose.)
> 
> 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
 * Just a note:  if someone implements this, remember to key by file and
   submitter so each person can have separate customizations.
> 
> 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 true!
 + users can easily send metainfo along with their files.
> 

> 4)
> 
> + works passably well with existing tools
  * This is wrong.  It works differently with existing tools.  Whereas the
    others all do nothing when you copy a regular file; this one has the
    potential to do the Right Thing or the Wrong Thing depending on filename
    and file glob. ex: in this directory I have file.html, file.html.bak, and
    run.html  If the info files are <filename>.info globbing works nicely for:
    cp file* finished_product/
    Breaks for:
    <rename> (globbing doesn't do what you need for mv file* foo* :-)
    cp *.html finished_product/
    
    I would regard this as a minus (being inconsistent is not a good thing.)
    
> + works well with mounted filesystems and removable media
  * Unless the media doesn't give the user permission to write to it (prevents
    customization.)  When this occurs, you ahve to fallback to #1 or #3 above.

> + simple to implement
> + users can easily share metadata
> - high inode cost
> - 'ls' gives litter
  - invasive procedure.  This puts file metadata everywhere in my filesystem
    (and no easy way for me to get rid of it.)
  - Breaks the UNIX convention of bin holding programs, etc holding system
    configuration, etc.
  - There is no way to turn this feature off!  (meaning with any of the
    others, I can ignore the existance of the metadata and everything will be
    fine.  With this one the metadata is sitting there in the directory so I'm
    forced to look at it whether I use it or not.  If I remove all the
    metadata on my machine somehow, I will find that anytime I install a
    package that uses metadata, I will have to go through every directory that
    the program installed to and redelete files.)  Also -- this will most
    annoy the people that want it least: People who use the shell are getting
    away from the world where meta-data is important -- but they're the ones
    who are going to have to stare at these metadata files....

#2 could be interesting, but we'd have to find a low cost daemon to serve the
data  (I seem to remember the last time the meta-data discussion came up
[Extended Attributes] it fizzled out with the vague promise that LDAP held
the key to the future....)  #1 or #3 could be implemented on top of any of
the others to give customizablility (#2 could provide its own customizability,
though.)  I frankly despise #4 because of its invasiveness.  I think it may
alienate people who don't want to move over from a shell environment.

Unless/until we can hash out some way to implement #2, I think a combination
of a system-wide file/directory structure and user file/directory structure
are in order.  (#1 or #3 with system-wide defaults)  Programs can put any
meta-data they have into the system-wide defaults.  Users can override system
defaults with their local meta-data files.

Creating a library that does this would  be a good idea -- that way we can
change internal formats without changing interfaces (ie: add a meta-data cache
or change to #2 or....)

-Toshio
-- 
badger  \"The Difference between today and yesterday is not so much what has
@prtr-13 \ changed between then and now as what I hope to change by tomorrow."
.ucsc.edu  \~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

PGP signature