Re: An answer to metadata, complete.
- From: Andreas Kostyrka <andreas rainbow studorg tuwien ac at>
- To: Kevin Littlejohn <darius connect com au>
- cc: gnome-list gnome org
- Subject: Re: An answer to metadata, complete.
- Date: Thu, 13 Aug 1998 19:44:48 +0200 (CEST)
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]