Re: An answer to metadata, complete.

[James Michael Mastros <spare jennifer-unix dyn ml org>]

On Thu, Aug 13, 1998 at 12:50:17 AM -0400, Leareth wrote:
> 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. 
Like I mentioned in another mail, regexes on filenames are a better, more
general idea...
Want a single file?  It's quite easy to make a regex for that.

This requires having multiple file data effecting one file -- which I think
we want anyway (all images should have some actions, and only one others,
for example).

I mentioned this in another mail... are you two too locked in a flamewar to
notice, did my post not make it to the list, what?

> 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.
We need to be _very_ careful with this idea.  If we advocate doing that as a
general usage thing, then we need to be _*VERY*_ careful that the VFS lib
(or, better, the portion of it that is LD_PRELOADed) is utterly, totaly,
100% bugless, or we will end up with some BIG problems with stuff failing
left and right, and likely killing the system.  And, we need to make it
HIGHLY effecent.

Really, I don't think keeping track of the few files that need _individual_
metadata of this sort over a non-gui action is worth the trouble involved in
LD_PRELOADing all over the place.

What metadata were you thinking of that needed to be...

Waitasec: cool idea alert.  How about this: when we have a bit 'o metadata
that we want per-file, store the pathname and a hash of the file.
Henceforth, if the hash OR the pathname match, we know we have the right
file.  The only problem is when you move _and_ change a file outside of the
GUI.

> 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...)
Windows dosn't keep metadata in a database on a per-file basis, but on a
per-extention basis, hence the RealMedia fiasco.  This is one of the things
promised in Cario, whenever _that_ is going to be.  I'm guessing just in
time for the new century -- 2100, that is.

Anyway, file management is, IMHO, one of the few things that Windows 95 got
more right then wrong...  And I don't feel dirty saying that: steel good
ideas wherever they came from.

	-=- James Mastros
-- 
A basement-GNOME (http://www.gnome.org/) with PIP (IETF group) and WINE
(http://www.winehq.com/).  Not really as impressive as it might sound, or as
Tolkinen.