Re: An answer to metadata, complete.

["Andy Coyne" <andy_coyne modusmedia com>]

This seems quite well reasoned, possible and above all beneficial to the user.

The .metadata files worry me a little, when changes happen through the CLI or
via NFS or whatever. I can see two problems immediately, lost/deleted .metadata
files, with data files intact - and lost/deleted data files with .metadata
files intact. I guess if Gnome identified one of these situations it could
attempt to locate the missing file, and give the user choices as to how to
handle the situation.

-Andy

Andreas Kostyrka wrote:

> On Thu, 13 Aug 1998, Kevin Littlejohn wrote:
>
> > *nix systems have a reasonably good way of identifying files already in
> > the 'file' utility - adding metadata to files seems a rather extravagant
> > way of duplicating this functionality.  Granted, you could maybe gain a
> > smidgen more control for individual files vs. classes of files, but it
> > seems a fairly high level of complexity to add for a small gain in
> > flexibility, to my untrained eye at least...
> It is a small gain if you do this manually. It is rather cool when your
> own HTML files open in your HTML editor (or even Emacs), while downloaded
> HTML files open by default in the browser.
>
> If done correctly, it would also allow applications to carry it's UI in a
> resource meta data in the binary.
>
> > I also would have thought that using something that already exists (ie.
> > magic numbers) means you're more likely to be able, as a user, to link
> > the behaviour under gnome into the behaviour of other, non-gnome tools
> > - so if I want a 'view file' command at a standard shell prompt that
> > calls a different viewer for different file types, basing it on existing
> > *nix utilities like file is a hell of a lot easier and more portable than
> > basing it on a gnome-specific 'metadata' system.
> All this has been rehashed for some time. The problem here is, that it is
> design question:
> -) Is GNOME to be first user friendly? If so file metadata would be
>    very useful.
> -) Is GNOME to be more or less a compromise with existing Unix traditions?
>    Then meta data could be a problem.
>
> Actually, I think that file metadata has many benefits:
> -) No central registry stuff like in Win95, each object (file) can design
>    at creation time how it likes to be opened, printed, etc.
>    (And centry registries/databases tend to throw up/become out of sync.)
> -) Not the broken ``extensions'' solution used in Win95, etc., but it
>    should used as a file ``class'' based fallback solution.
> -) In my opinion it can be done in a UNIX compatible way, but it is some
>    work.
>    *) By default store the metadata in filename.metadata
>    *) For ELF binaries store it in the binary directly.
>    *) For existing formats like TIFF, sh scripts, etc. that know
>       about comments, store it in a comment.
>    *) For new Gnome filetypes, store it in a standard way.
>
>    I know this is NOT nice, but considering that metadata usually will be
>    small (<1KB) I'd say, this ``inline'' (better infile) storage method
>    should be acceptable for many formats.
> -) As the metadata would be most often in the file directly, no problem
>    for the Unix shell. You would have still to watch out for .metadata
>    files.
> -) On free systems, one actually could patch the GNU file utils to
>    ``cover'' the metadata files, and automatically take it into account.
>
> Andreas
>
> --
>          To unsubscribe: mail gnome-list-request@gnome.org with
>                        "unsubscribe" as the Subject.
>