GnomeVFS ioctls, live metadata and dead metadata

[Ian McKellar <yakk yakk net>]

Hi,

We've all got different things we want to do with gnome-vfs and most of 
them can be described in a sentence that includes the word "metadata". 
Heres what I see as the different sorts of data that applications want 
to deal with
 * file stream data - bytes that are in the file - gnome-vfs handles 
this well enough
 * posix file metadata - size/name/permissions - the stuff we get back 
from stat and put into a GnomeVFSFileInfo
 * dead extensible metadata - extra information that applications can 
attach to a file (eg: emblems)
 * live format-specific metadata - information that can be inferred 
from the file-stream and/or posix file metadata but is file format 
specific (eg: id3 tags, word author...)
 * live scheme-specific metadata - extra information a gnome-vfs module 
might want to provide to an application about a stream or a uri (eg: 
webdav metadata, https cert info, http headers)

File stream data and posix metadata are already supported in GnomeVFS. 
I think that dead extensible metadata would be a worthwhile addition to 
GnomeVFS - its already in Nautilus but it being in GnomeVFS would make 
the file-dialog work easier among other things. I think scheme specific 
metadata needs to be in GnomeVFS by definition because its specific to 
the different filesystem backends that exist. I'm not sure that 
format-specific metadata belongs in gnome-vfs. I certainly don't think 
it can or should be mixed in with other forms of metadata.

So I think we need an API in GnomeVFS for dead extensible metadata in 
gnome-vfs that lets us get/set values on URIs, probably with some other 
information like modification date (eek - metadata metadata).

I think that having an API that lets retrieve format-specific metadata 
would be really cool. Perhaps this could even transparently cache the 
result in dead metadata. It should be plugin-based so that we can 
extend it and applications can install handlers for their own 
file-types.

For scheme-specific metadata we could either provide an additional API, 
try to fit it in with the dead metadata or try to fit it in with the 
concept of ioctls. I'm not sure whats best. I guess I would prefer the 
first option, otherwise we'll end up with a set of standard ioctls for 
retrieving metadata and those are effectively second-class fileops. Why 
not just make them fileops?

What do you all think?

Ian