Re: ioctls for gnome-vfs


On Tue, 2002-11-19 at 04:20, Alexander Larsson wrote:
> 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.

This is fine, I just want proof that an ioctl interface is viable and
absolutely needed before adding more API to vfs.  Thus far I haven't
heard a good enough use for one.

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

if these are included in the file's id3 tag section, and is not
reading/editing content, whats the issue?

> Word document:
> * the embedded author name
> * word count

these are included in the word file's metadata section.

> * list of figures
> * table of contents
> * automatically generated summary

these are not, and therefore aren't accessible.

> HTML document:
> * encoding from metatag

sounds cool.

> * word count
> * list of sites linked
> * preview thumbnail of page

all of these are content, so no.

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

What I want is a tags library in vfs.  Not content parsers.  There are
enough file formats where metadata is specifically sectioned off that
this seems useful.  

But this also leaves the window open for custom vfs methods to support
wacky metadata, like http headers, or the the target filename of a
virtual file-system.

Anyways, I'm willing try out a library that layers tags on top of vfs's
metadata storage (using the same api as vfs-metadata).  One that will
first see if a given metadata tag is supported by the mime-type, and if
not falls back to gnome-vfs' metadata api.  If applications begin to use
it and it works out okay, we can reevaluate if it should be rolled into
vfs.  Cool?


 on the canvass of life, incompetence is my paintbrush.

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