Re: Meta-info on files

[Andreas Kostyrka <andreas rainbow studorg tuwien ac at>]

On Tue, 21 Apr 1998, Ben 'The Con Man' Kahn wrote:

> On 21 Apr 1998, Russell Nelson wrote:
> 
> > Everybody seems to want meta-info on files.  I propose this plan
> > (which, regardless of its merits, is at least New!  Different!  On
> > Sale at your Local Grocer's Now!):
> > 
> > There's a library for dealing with file types.  Ordinarily, the
> > library identifies files two ways: One, it looks them up in
> > /usr/lib/magic.  If the file is a known type, it gets assigned a MIME
> > type.  There's a lookup table which assigns properties (icon, viewer,
> > editor, whatever) to the MIME types.  That's easy enough, and 90% of
> > it is there.  The other method is to look up the filename in a
> > database and assign MIME types that way.  That way, *.g3 files get
> > identified as fax files, since they don't have a magic number.  And
> > programs, which would otherwise get a generic "executable" icon, could 
> > be assigned individual icons.  And files in /var/spool/fax/incoming
> > would be identified as faxes even without a g3 extension.
> > 
> > The NewDifferent part is to create a new file type (call it, say,
> > GnomePack, with a .gp extension) with a new magic number.  When a
> > GnomePack-cognizent application loads up a GnomePack file, it knows
> > that there is a resource fork and a data fork.  Any items in the
> > resource fork override the properties which would otherwise comes from
> > the MIME properties table.
> > 
> > Obviously, this works great across NFS, FTP, HTTP, and generic Unix
> > filesystems.  It works great with all file manipulation packages, cp,
> > mv, ln, tar, cpio (etc).  It doesn't work transparently from
> > application to application.  However, that isn't a killer, because we
> > don't have to be stupid about it.  The headers can be text instead of
> > binary.  So, text editors will deal, if the users are just barely
> > smart enough to leave the headers alone.  And we can have a pair of
> > programs, ungp and regp which remove and create the header.  And
> > gnome-libs can have "readdatafile" and "writedatafile" functions which 
> > take care of removing/creating the headers.
> 
> 	So a gnome application would have this text header?  So this would
> be a small shell script?  Does that mean that the internal application
> will have to be unpacked from the file to be run?
Nope:)
It's again ``my'' resource idea. But it's a quite clever way of
packaging the resource fork:
- GNOME specific files -> use the Gnome Package format.
- The most important file types are handled also in the data file.
  For example, almost all scriptlike languages can be handled by one
  implementation, that packs the resource fork (that contains handling
  info, icons etc.) in comment lines starting with #
  Same here for HTML files, etc.
  Ok, it may make files bigger, etc., but they are still basically
  intact, and you can move,backup,restore,transfer, etc. them with
  traditional UNIX utilities.
  In binaries, this can mean also the storage as an ELF section, ...
- The other file types, this means the ones, where format is 100%
  inextensible, or unknown, kan still be handled with an info file if
  needed.
- Actually, the defaults are all recognized with file, and if it fails
  via the extension. .info files are only created if the user changes
  something.

Having for example all resources in the binary makes for one cool thing:
Application that consist only of one file. I know rpm's are vital for
proper system administration, but if the user wants just to install this
new mpeg player in his home directory, than this is the prefered way of
dealing with this. (Again this is something Mac specific: No installation,
etc, just copy the app from the CD to the hdd, and it works :) )

Amd one important thing is, that while GNOME has to cater for advanced
Unix users, it also has to cater to novice PC/Mac users.
This compromise for storage of Meta information is in 9x% compatible with
the Unix way, doesn't require new VFSs, and still can give GNOME all the
benefits, that make MacOS even today win in comparisions in the press with
Win95. (except the pure technical things like memory management, or
multitasking *g*)

Andreas