A Question about Metadata storage



	-----Original Message-----
	From:	Daniel Veillard [SMTP:Daniel.Veillard@w3.org]
	Sent:	Tuesday, August 18, 1998 1:51 AM
	To:	tromey@cygnus.com; Gnome Mailing List
	Subject:	Re: A Proposal for Metadata

> I agree that this makes things far less trivial, I believe that that makes
> them far more useful too. I don't even give the slighliest idea about how
> to actually implement this, but I guess that the debate need first to be
> focused on what do we need, before jumping into implementation tricks.
> 
	I know I kind of added a bit of fuel to the discussion with some of
my earlier comments, but I was just curious to what extent options for
storing the metadata were looked at. Some people are advocating storing them
in the filesystems (ext2 for example) that support that functionality (re:
HPFS from OS/2 and their Extended Attributes), or having a data-file on fs
that don't support it (what OS/2 did on FAT filesystems); others have
suggested NeXTstep-like .app/.lib directory wrappers (which makes this
completely fs independent AND has the side-benefit of working over different
OS's fs mounted via NFS, SMB, etc.). Still another suggestion I saw was to
store this information in an on-line database (serious performance
problems).

	One thing I'm curious about, since GNOME is "Network Object Model
Environment", has anyone looked into the possibility of using ACAP as a
"registry". That would provide a networked repository for "registry/ini"
type settings, and is "somewhere between a directory (like LDAP) and a fs"
as paraphrased from the ACAP page.

	http://andrew2.andrew.cmu.edu/cyrus/acap/

	If ACAP is viable, it would fit nicely, I believe, into the GNOME
"way". It allows configuration data, which can be conditional, to be stored
in a network "registry".

	I think that if possible, it'd be extremely useful for environment
settings (i.e.: work or home, 8 bit frame buffer or 24 bit..., etc.),
metadata, and configuration could be available no matter where you logged
in.

	Obvious questions come to mind, such as performance. (Could be
worked around in a "cached" setting, where changes were made and
synchronized in the background, or on confirmation, or even at logout, etc.)
Having not run an ACAP server, and not knowing of any ACAP applications to
test against the ACAP server once I build it, I don't have any specifics
other than what is available at the above listed URL.

	Just more fodder. Comments?

	-j



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]