Re: ioctls for gnome-vfs

[Alexander Larsson <alexl redhat com>]

On 19 Nov 2002, Alex Graveley wrote:

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

They are not. live metadata is data computed from the content, and I 
definately do not want live metadata.
 
> > 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.  

I don't see why it is more useful than a libid3 for a mp3 player and 
libgsf for Word documents. Both of those libraries are much better suited 
to the corresponding app than a generic tags library. What if you have the 
mp3 header in memory already? How do you use gnome-vfs metadata then? 
 
> 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?

I'm fine with that of course, since I probably won't use it. It could even 
use an ioctl to implement the per-method wacky metadata. :) 

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a lonely umbrella-wielding jungle king on the run. She's a foxy 
African-American museum curator married to the Mob. They fight crime!