Re: ioctls for gnome-vfs

[Alexander Larsson <alexl redhat com>]

On 18 Nov 2002, Ian McKellar wrote:

> Hi guys,
> 
> I can see the value of both ioctls and metadata. In fact, probably
> ioctls on handles & uris and metadata on handles & uris. Ioctls can be
> used to control something about the uri - for example telling a cdda://
> uri to eject, and metadata can be used for getting/setting arbitary
> properties.

Right.

> If we look at the WebDAV model of metadata they classify metadata
> properties into two categories: live and dead metadata. Live metadata is
> derived from the files themeselves, it includes stuff like size,
> mime-type, etc. Dead metadata is attached by applications. I think the
> distinction is important.

The reason I dislike automatic handling of live metadata the way alexg 
proposes it is because it is so open-ended. Consider these types of live 
metadata:

Mp3 file:
* id3 author data
* play time
* BPM count
* frequency graph

Word document:
* the embedded author name
* word count
* list of figures
* table of contents
* automatically generated summary

HTML document:
* encoding from metatag
* word count
* list of sites linked
* preview thumbnail of page

As you see, this really becomes a way to do arbitrary transforms on a 
file. And while this is a useful thing to do (I mean, the shell does 
mostly the same, and it's useful), pretending that all possible results of 
such transforms are properties in metadata is just not a good API. Using 
the property name to encode what transform to run in an add-hoc fashion 
and then try to parse the output in add-hoc ways is not gonna make it 
easier for programmers than the already existing domain-specific 
libraries that are availible. Not to mention the pains in e.g. trying to 
report html parse errors in a GnomeVFSResult. 

As I see is, the difference between the ioctl approach and the live 
metadata approach is one of scope. ioctls are used to do the minimal 
operations you absolutely have to do, while live metadata is this 
super-generic thing that just screams of plugging in Word import filters 
and html renderers into the filesystem, making it large and unstable in a 
way that doesn't really help application authors.

> I'm really not sure if we should be transparently extracting id3 and
> word author information from files transparently, but I think it might
> be appropriate for applications that are interested in id3 tags to cache
> the information in dead metadata once they've read it. This means of
> course that we need to keep track of modification times on metadata.

Sure, that makes sense.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a lonely guitar-strumming shaman on the edge. She's a tortured impetuous 
single mother living on borrowed time. They fight crime!