Re: Icons of program

[Fred Bacon <bacon mediaone net>]

Miroslav Silovic wrote:
> 
> Matt Kimball <mkimball@xmission.com> writes:
> 
> > And I don't see that much difference between a filesystem and a
> > registry, really.  People argue that it is too unsafe to store
> > important system information in a database like that, but isn't that
> > what a filesystem is?  Just because Microsoft came up with a poor
> > implementation doesn't mean that the whole concept is bad.
> 
> You also missed the fact that registry is not human-readable. Meaning
> you need special tools to edit it, and the special tools are only
> available when Windows are already running. So once you hose registry
> beyond recovery, if you don't have a backup, there is absolutely no
> way to fix the problem (short of reinstall). 

I wish I could whistle in print.  No wonder people hate the registry.

The same can be said of the file system.  It's a binary representation
which can make the system unbootable if it becomes corrupted.  I know,
I've done it. :-)

> UNIX textfiles are
> editable by hand so the system can always be brought back into a
> bootable state (well, as long as filesystem is still alive) - you just
> boot it from the floppy, mount the hard disk and edit the
> configuration.

A couple of things.  I don't believe that anyone is suggesting that we
should put anything into the meta-info database which would make the
system unbootable should it fail.  I can't believe that MS did.  What a
stupid move.

It isn't necessary for you to have a text file based system to recover
the database from a single user login mode command line program.  It is
only necessary to have a non X Windows based utility to do this.  Rpm is
perfectly capable of rebuilding it's database from the command line. 
The gnome's meta-info database could be equally recoverable.  In fact,
one of the arguments against a text based system, is that it would be
too easy for a novice to violate a format and break things.

Furthermore, the database should be there only as a rapidly loadable
binary image of the system's internal data structures.  The question is
really how do we generate that information.  Once that question is
answered, recovering from a catastrophic database failure is simple. 
The database shouldn't be the only source of meta-information, it should
be the central clearing house for this information.  One application
would be responsible for building it and keeping its information up to
date, and everyone else can query it.

The real question is how to build/rebuild the database.  I think the
answer is to have a wide variety of ways, each of them providing a
greater degree of specificity.  Mime-types and magic numbers at the
broadest scope and a utility to allow a user to alter the
meta-information on a file by file basis at the narrowest scope.  In
between there can be a range of possibilities, limited only by the
requirement that the information is passed to the database via a well
defined API.  How difficult can it be to add a little routine to
ElectricEyes (very cool program, btw) which would specify an appropriate
icon for gnome to use for the files it creates.  Now I can tell a jpeg
create by xv from a jpeg create by ee.

At the very worst, if the db is totally corrupted, then you might lose
some of your nice pretty personalized icons, but they won't really be
gone.  You just have to reenter them.  The database will reconstitute
itself from its default mime-types.  The original icons will still be
safe and sound in their original locations--a directory, the creating
application, stuck to the bottom of your shoe...wherever you last left
it. 

I've never looked to see how mc works inside, but I would be surprised
to discover that it didn't cache directory information.  My suggestion
is to create an application agnostic cache that can be shared.

> 
> Basically a large binary file that can only be modified if GNOME is
> already running can be equivalent to locking the car keys inside your
> car.
> 

I agree.  This would be dumb.  But it isn't necessary.  See above.