[Nautilus-list] Metadata Ideas


I've been working a bit on the new metadata model design. From the 
application's perspective I've come up with this:

/* Proposed GNOME VFS Metadata API */

/* type of query callbacks */
typedef void (GnomeVFSQueryCallback)(GnomeVFSURI uri, gchar *namespace,
  gboolean children, xmlDocPtr xml, gpointer user_data);

/* attach metadata to an URI and namespace [does not block] */
void gnome_vfs_metadata_attach(GnomeVFSURI uri, gchar *namespace,
  gboolean shared, xmlDocPtr metadata);

/* query metadata for URI and namespace [blocks] */
xmlDocPtr gnome_vfs_metadata_query(GnomeVFSURI uri, gchar *namespace,
  gboolean children);

/* query metadata for URI and namespace [return result via callback] */
void gnome_vfs_metadata_async_query(GnomeVFSURI uri, gchar *namespace,
  gboolean children, GnomeVFSQueryCallback callback, gpointer user_data);

/* detach metadata from an URI and namespace [does not block] */
void gnome_vfs_metadata_detach(GnomeVFSURI uri, gchar *namespace);

VFS modules could optionally implement attach, detach and query routines.
If they don't implement these, or they return an error then gnome-vfs will
fall back on an internal implementation. For shared metadata a
.gnome-metadata.xml file in each directory (with the same access 
permissions as the directory if possible). For unshared metadata an XML
file in ~/.gnome-metadata/ for each directory would contain the metadata.
If its not possible to write dir/.gnome-metadata.xml, gnome-vfs will
fall back on files in ~/.gnome-metadata/.

I think this model is flexible an efficient enough for Nautilus and other


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

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