Re: An answer to metadata, complete.

[Kevin Littlejohn <darius connect com au>]

For the benefit of those of us who may not have a complete view of this
problem:

What's the flaws of a system that uses something like the 'file' command,
and a personal database of file-to-application mappings?  So, there is a
system-wide, gnome-wide database that says 'ascii text' types are opened
with vi, and individual users can change that to be pico if they wish?

*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...

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.

KevinL
(running Linux and multiple flavours of SunOS, with multiple WMs and multiple
desktops:)

> Ok, hitme.
> Give me a way to keep track of how documents are:
> 	printed,
> 	shown on the screen(icons),
> 	set to be open by a app,
> 	you get the picture...
> 
> AND!!! (big and here),
> Do so in such a way that,
> 	A: Any user can add such setting to any file he/she wish's,
> 	    and not mess up any other user's setting's on sed file.
> 	B: Any user/program can, without worrying about weather or not
> 	    the program was linked with a special library, move these files
> 	    around without any of the setting(for as many user as have
> 	    setting's set upon the file) being lost.
> 	C: Setting may be set upon any file open to viewing from the vfs,
> 	    includeing file's within archives(zip,tar,rar,etc...), or remote
> 	    sites(ftp basicly).
> 
> You up to it? Mine is the only way I've seen that meet these critera, and
> I was one of the few that actually paid attention to the thread while it was
> here. 
> 
> REMEMBER, apps must be able to modify the file(s), includeing
> moveing, name changeing, and anything else, WITHOUT being linked
> to the library controling the access to the metadata, or modifyed from
> it's current state in any way, while still keeping track of all users
> metadata that may or may not be atached to the file.
> 
> There are, as far as I can tell, only 2 ways to do this, my way, and mac's
> way. (eg, make a new file system, and have it support all of the above,
> only problem being, it only works for linux, as other OS's will be unlikly
> to adopt it as standard... actually I dout even we(the linux community),
> would accept such a change)
> 
> Good luck, if you can find a simpler/faster way, I'm all for it, but only if
> it can do the above. My way is so simple as to only require one library,
> one ENV setting, and a central database thats quite light weight + one
> extra database per user that uses the system. For what it's doing, and
> doing it invisably at that, it's rather simple.
> 
> 
> On Wed, 12 Aug 1998, Adam Chodorowski wrote:
> >> ** Allow data on the system to have arbitrary, but structured 'meta-data' **
> >> ** Make sure that 'meta data' and 'data' can't get out of sync. **
> >
> >And what is this meta-data good for? I can't see anything usefull coming 
> >from it, that you can't implement in some other, much simpler, way.
> >
> >-- 
> >Adam Chodorowski (archmage@earthdome.com)
> >
> >
> >-- 
> >         To unsubscribe: mail gnome-list-request@gnome.org with 
> >                       "unsubscribe" as the Subject.
> --
> Leareth <leareth@geocities.com>
> -- You've got to lose, to know how to win
> 
> 
> -- 
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
>