Re: GnomeVFS ioctls, live metadata and dead metadata

[Alex Graveley <alex ximian com>]

Hi,

On Thu, 2002-11-21 at 22:04, Jody Goldberg wrote:
> On Tue, Nov 19, 2002 at 04:34:50PM -0800, Ian McKellar wrote:
> > 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 we can deal with these features when it becomes
necessary/applicable.

> > 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 is what I was proposing, but everyone seems to want this first
demonstrated in an external library (possibly egg?) which sounds smart
to me.

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

Only on-demand from an application, I would hope.

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

Hopefully with internal utilities for caching and persisting (in the
home directory as nautilus does now) that all methods can use as a
fall-back.

> 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). 

I'd really like to keep value definitions out of vfs.  Maybe we can ask
the glib people about adding blobs and timestamps as standard gvalue
types?

> 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

If you're doing this you're codifying content metadata, while not
providing the means to access it.  We should leave this up to the
external content metadata library.

-Alex

-- 
 on the canvass of life, incompetence is my paintbrush.