Re: [Nautilus-list] Metadata model

[Ian McKellar <yakk-nautilus yakk net au>]

Revised ideas for gnome-vfs / Nautilus metadata.

* If we're going to only have two depths why not express that as a
  gboolean? I've replaced "GnomeVFSMetadataDepth depth" on
	gnome_vfs_metadata_query with "gboolean children", which when set would
	indicate that the metadata for the node and its children were desired.
	I'm not sure about the format of the return value for this. For a
	children=FALSE query the return could be the set of elements for that
	particular node, but a children=TRUE query would either have to return a
	GList or GHashTable (and as such would need to be a separate call) or we
	would have to develop a set of elements to represent the structure. For
	example:
	<gnomevfs:collection gnomevfs:xmlns="http://www.gnome.org/gnome-vfs/1.0/";>
	  <gnomevfs:resource><apptag>...</apptag></gnomevfs:node>
		<gnomevfs:resource name="foo.txt><apptag>...</apptag></gnomevfs:child>
		<gnomevfs:resource name="bar.txt><apptag>...</apptag></gnomevfs:child>
	</gnomevfs:collection>

* I'm not convinced of either the worth or feasibility of publicly
  writable (METADATA_TYPE_SHARED) data. Firstly I can't think of a reason
	that you would want metadata to be writable by everyone and secondly its
	unlikely to be portable to non-local filesystems. What I think would be 
	better is simply a share/unshared flag you can set when attaching 
	metadata that would indicate if the metadata should be stored in a 
	special database in the user's home directory, or if it should be stored
	(if possible) as close to the resources it describes (for example in a 
	dot-file in the directory). This is implemented as "gboolean shared".
	The shared metadata could by default inherit the permissions of the
	directory its being stored in.

* The gnome_vfs_metadata_(attach|detach) functions never return anything
  anyway, so they should be async anyway. gnome_vfs_metadata_async_query
	is an idea for an async version of the query function. I've never used
	the gnome-vfs async APIs - is this appropriate?

* Darin mentioned a wish to allow the reading of less than a full
  namespace of metadata for a given URI. I'm at a loss for how to specify
	this. I'm more than open to ideas. A SAX-style interface perhaps?

* Darin also mentioned locking. Again I don't have too many ideas here.
  For locally stored, private metadata its quite easy. For shared and
	non-local metadata its less so - it becomes the distributed database
	synchronisation problem. Perhaps a lock request could be declined if
	locking isn't going to be possible.

* Finally theres the modified date issue. Is there a need to be able to
  retrieve the last modified date or would a IfModifiedSince version of
  _query be the way to go?

Heres home of the proposed API:

void gnome_vfs_metadata_attach(GnomeVFSURI uri, gchar *namespace,
  gboolean shared, xmlDocPtr metadata);

xmlDocPtr gnome_vfs_metadata_query(GnomeVFSURI uri, gchar *namespace,
  gboolean children);

typedef void (GnomeVFSQueryCallback)(GnomeVFSURI uri, gchar *namespace, 
	gboolean children, xmlDocPtr xml, gpointer user_data);

void gnome_vfs_metadata_async_query(GnomeVFSURI uri, gchar *namespace,
  gboolean children, GnomeVFSQueryCallback callback, gpointer user_data);

void gnome_vfs_metadata_detach(GnomeVFSURI uri, gchar *namespace);


Please eat, ruminate and provide comments.

Ian (who shouldn't be writing this kind of thing at 2:30am)
-- 
Ian  McKellar |    Email: yakk(a)yakk.net |    Web: http://www.yakk.net/
Area: +61 (8) | Home: 9389 9152 | Fax/Voice: 9260 2903 | Work: 9384 4700