Re: An answer to metadata, complete.

[Kevin Littlejohn <darius connect com au>]

> 
> It wasn't ment to replace the "file" command, or even to id file types,
> my sujestion was for the single files, not file types.
> I could care less how you decide to handle file types,
> I want set data on ANY single file, and have it tracked inside & out
> of the file type library. I want to set the icon for /home/joe/readme.txt
> and have to still hold when I open a shell and "mv" the file. If we
> are to have only genral file types, my interest in this project is lost...
> 
> No ofence intended, I'm in a bad mood anyway, and I've had to do
> this explaination 1 to many times to still sound patient.

That's fair enough :)

So the problem is split in two - a mechanism for general classes of files,
and a mechanism for individual files.  If you're seriously thinking about
placing these functions in a library, please make it a seperate library
with seperate functions rather than a library that somehow overrides the
libc - that's just asking for trouble, and makes it difficult to apply
easily in some environments.

And bear in mind that if you're holding 'no synchronisation problems' up
as one of the plusses for any particular method, it's probably invalid -
_every_ approach runs the risk of synchonisation problems, if it doesn't
rely on a new filesystem of some sort, or get fairly intrusive in the non-
gui case.

That's all I wanted to say really - I don't think LD_PRELOAD gives you
the benefits you claimed in your earlier email, to whit:

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

That's doable in just about any scheme

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

This is bogus - you can't give that, as far as I can see, without forcing
_every_ gui and non-gui binary to use this new library - and there's just
way too many environments where that's not an option.  Anything you do _has_
to take desynch into account.

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

Again, that's doable in just about any scheme, save the case of putting the
metadata in the file itself (which I'd just like to say, for the record,
scares the bejesus out of me :)

My own preference, after listening to this stuff, would be for classes based
on 'file'-type, and for each user to have a database of hashes for files.
That looses the metadata across users, unfortunately, but I think maybe
that's reasonable?  I also think tying it all into a single file-per-user
that contains hashes and instructions is better than sprinkling .meta files
around the filesystem - less chance for desynchronisation, and less of an
overall performance hit.

Having said all that, I'm not the one doing the coding - so my ideas should
be valued accordingly :)

KevinL