Re: An answer to metadata, complete.

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

On Thu, 13 Aug 1998, Nelson Minar wrote:

> >-) Is GNOME to be more or less a compromise with existing Unix traditions?
> >   Then meta data could be a problem.
> 
> Is someone seriously proposing changing the way Unix does files for a
> nice GUI? That seems very unlikely to me.
Not nice. Functional and user friendly. That's the point.
> 
> >Actually, I think that file metadata has many benefits:
> 
> It's a nice thing, but Unix just doesn't have it. The MacOS model of
> files is really quite nice, but if you take a look at how well it
> interoperates with flat file systems like Unix and Win95 you'll
> quickly be scared away from trying to integrate metadata with Unix.
So what you are basically telling here, that Unix doesn't have
some basics for important GUI features. So we will just leave out the good
stuff. That's bad attitude in my eyes, sorry.

Another thing:
Win95 does many things wrong:
-) extension based. extensions are the worst base for detecting the file
   ``class''. file is by far the superior choice :)
-) global registry, that is text mode non editable. (That's an invitation
   for locking oneself out of the system. To edit the config I need the
   GUI, but without editing the config the GUI doesn't start.)
-) No instance level metadata. That makes programs grab the whole
   ``extension'', instead of marking their data files as theirs.
-) The abstraction is basically already broken in the GUI.

So my position is, that the fact that Win95 isn't able to cope with
file ``types'' correctly, is just an invitation to try to be better, not
to resign (``See, it's undoable, so don't try.'', but then with this
Motto, the native americans would be still the majority of americans *g*).

*) For a good GUI, MetaData is more or less needed. (See for example NeXT,
   where this kind of stuff lead to using directories as ``objects''.)
*) The abstraction at the GUI level should be 100%.
*) The abstraction at the CLI level is less of a problem, and probably not
   doable completly everywhere, some options:
   -) Make it systematically non-transparent: So every GNOME file has
      .meta companion. This relies on ``reconditioning'' the Unix Gurus.
   -) Try to hide the non-transparent:
      .) By hiding the meta-data if at all possible in the file proper.
         (comment entries, etc.)
         Advantage: In some places this could get 100% transparent.
         Disadvantage: It's nonuniform :(
      .) By patching the basic system utilities.
         Advantage: Could make it really transparent.
         Disadvantage: Non-patched utilities tend to loose meta data if
                       they move the file. It does not work for systems
                       where you do not have the source.

IMHO, GNOME tries to build the ``best'' GUI environment, so the priority
should be at getting a good GUI. The CLI is of secondary importance in
such a project. (No I'm not argueing that CLIs are unimportant. But
nowadays, the GUI tends to be more important. And CLIs are usually so or
so much more flexible, so they can be made to work with .meta files with
some thought of the user.)

Andreas
-- 
Win95: n., A huge annoying boot virus that causes random spontaneous system
     crashes, usually just before saving a massive project.  Easily cured by
     UNIX.  See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.