Re: An answer to metadata, complete.

[Leareth <leareth geocities com>]

Oh yes, useing the "file" program for defaults is the right way to go,
I agree, but that does not negate anything I said. The use of "file" would
only work for system defaults, user setting on single files would have no use
for it. Now if your stating that haveing control down to a single file is not
needed, well it's an opinion, and in my view a short sited one. No ofence
if thats not what you ment. Personaly, a gui without true metadata, on
a per file basis, is not only less functional, but almost useless. Metadata
IS the only use I have for gui file management, with out it, I'll take bash
any day. I like gui's, but a gui must be good enough to exceed what I'm
already useing. eg, X + many xterms. And you'll also note that, metadata
without the ability to keep track of it out side it's control library(1), is
as useless as no metadata, imho.

1: eg, you have metadata atached to a file, go into bash and "mv" the file,
some where else. Databases alone can not handle this, but takeing from
libvfs's use of LD_PRELOAD to over ride basic libc functions, with extened
versions that can be used to track the files, and keep databases updated.
Contrary to your belife, this is not a costly system, as any desktop that
has metadata in a database (CDE,dfm,dare I mention windows? I feel dirty...)
do this anyway, but at the library level. This means that there databases get
corupted. Gnome, with out this system, will end up useing user level databases
anyway, as sevel developers have agreed that metadata is nessessary, but
with this system, the tracking code is moved to a global state instead of a user
state, so database coruption will not be possable with the exception of system
crashes. The speed will be the same either way, but one has far greater
functionality.

On Thu, 13 Aug 1998, Kevin Littlejohn wrote:
>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.
>> 
>
>
>-- 
>         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.