Re: An answer to metadata, complete.

[Derek Simkowiak <dereks blarg net>]

> >    A much better approach would be to implement a database of different
> >    filetypes, and means to recognize files of different filetypes.
> >    Ofcourse the filetypes should be configurable (by the administrator).
> 
> Agreed.

    Howdy,
	I haven't been following this thread to closely, so my apologies
if this has already been brought up.

	What you're talking about has already been implemented.  Look at
what I can do from my Redhat prompt:

[dereks@localhost dereks]$ file Words.aw.ps 
Words.aw.ps: PostScript document text conforming at level 3.0
[dereks@localhost dereks]$ file delme.txt 
delme.txt: English text
[dereks@localhost dereks]$ file delme.gif 
delme.gif: GIF image data, version 89a, 118 x 100,
[dereks@localhost dereks]$ file em-1.16.tar.gz 
em-1.16.tar.gz: gzip compressed data, deflated, original filename, last
modified: Sun Jul 26 16:14:43 1998, os: Unix
[dereks@localhost dereks]$ file pilotmoney.html 
pilotmoney.html: exported SGML document text

	...I think the "file" command looks at the file headers, and does
not use extensions.

	All GNOME needs is a database that:

1) Associates a default icon with a particular file type
2) Associates a default editor/viewer with a particular file type
3) Has an easy way to let new programs register their new file types
4) Deals with individual files <-- THIS IS THE TOUGH ONE

	This database could be as simple as a pre-defined directory name
that has a list of files, which are graphical icons that have the editor
info built-in to the foramt, that correspond to particular filetypes.
I.e.,

~/.gnome/file_registry/
		|_____
                      tarball.info
                      postscript.info
                      HTML.info
                      gif.info

	(of course, a more thought-out naming scheme is required)

	In regards to the requirements listed above:

1 & 2) If the .info file are a format like GIF, the editor info could be
kept in the comments of the file (hey, don't XPMs also allow for
comments?)

3) A new program could register its proprietary file type by simply
copying a new .info file into the pre-defined directory during the install
process.

4) Dealing with individual files is the tricky one.  If I have a
postscript file sitting on my desktop, and I want to give it a silly
Calvin&Hobbes icon, how do I do that?  If I then rename that postscript
file in the shell, what happens?  Perhaps a database of
individually-modified files that includes info such as file size, mod
date, access date, owner, etc.?  This is where things get ugly.

	Maybe we could use the .AppleDouble filesystem that netatalk uses.
It was invented to specifically get around this kind of problem.  Of
course, then we need to use the same .info format as the Mac... :(

	Finally, there is a performance hit in scanning directories when
you read the headers for each individual file (especially in directories
like /dev/ or /usr/lib/ ).  But with efficient caching, this should not
be to big a deal.  After all, Window 95 does it and its directory-reading
is livable.

--Derek Simkowiak
  dereks@blarg.net