Re: GnomeVFS ioctls, live metadata and dead metadata

[Jody Goldberg <jody gnome org>]

On Tue, Nov 19, 2002 at 04:34:50PM -0800, Ian McKellar wrote:
>  * 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)
Nicely put.  That clarifies things.
 
> 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).
That would elimiate the need to support some of the obscure features
of MS Office 'live format-specific metadata' such as linked values.
The only downside would be that one of the common elements in there
is a file preview image which would be generally useful.

> 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.
This raises a question.  What sort of performance constraints do you
see for tis 'dead extensible' metadata ?  Are we going to be
sucking it in for 10,000 files in a large directory ?

> 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?

metadata != ioctl That seems obfuscating
If we are comfortable with a
    GValue *handle_get_metadata (GnomeVFSHandle *handle, char const *name)

style of interface then it seems like the problem splits into 3
elements

1) per module mechanisms for persisting and caching the data

2) A couple of convenince value types in gsf or gnome-vfs to store
   common data types that aren't predefined.  eg in the paritial
   implementation in gsf I have binary blob and a timestamp object
   (with timezone support). 

3) Ideally some accord on naming the tags so that similar types of
   metadata from different formats will use the same tags. 
   eg ogg vs mp3  or OLE vs OO Zip