RE: metadata proposal

["Dries, Joseph" <joseph dries lmco com>]

> -----Original Message-----
> From:	Christopher Curtis [SMTP:ccurtis@ee.fit.edu]
> Sent:	Thursday, August 20, 1998 12:21 AM
> To:	gnome-list@gnome.org
> Subject:	metadata proposal
> 
> I've taken Tom's excellent proposal and modified it as I've seen fit
> (there was little to dispute).  It is available at
> http;//www.ee.fit.edu/users/ccurtis/metadata.html
> 
> I would appreciate hearing any feedback and would love to answer any
> questions.  Please send feedback to the list and questions directly to me.
> 
> thanks,
> --
> Christopher Curtis               - http://www.ee.fit.edu/users/ccurtis
> 
	I find both of these proposals heading in the correct direction. I'm
happy to see that. One question that has been nagging in the back of my
mind: I agree that a system that depends on metadata the best solution would
be support in the filesystem for metadata, much like the Mac and OS/2 do.

	The detail that I'm concerned about is that anyone who goes in that
direction (adding support for ext2, or other *BSD, Solaris, SunOS, AIX,
IRIX, etc. filesystems) how would that solution handle the metadata for a
large number of users. MacOS and OS/2 didn't have much of an issue because
they assumed a local user context. True, there were server versions of OS/2,
and I don't know how OS/2 handled attributes on a per-user basis, if it did
at all. If I recall correctly, it only handled attributes per object, such
as a file, not assuming >1 user.

	Specifically, if users go adding comments, icons, etc. to a file. In
an environment where I have nearly 4000 users, that's a large amount of
metadata to store in the filesystem for one file. (Of course all those users
will be accessing those files via NFS, so that detail needs to be worked out
in a portable manner).

	I realize both proposals decouple the metadata API from the storage,
and I believe that is the correct if not necessary way to go. I also have
seen many people indicate that the fs is the right place for the "database"
on systems that support it. I just wanted to illustrate some issues that
might make this solution infeasible for a multi-user contexted system such
as Unix.

	-j