Re: ioctls for gnome-vfs

[Ian McKellar <yakk yakk net>]

On Monday, November 18, 2002, at 08:46 AM, Alex Graveley wrote:

> On Mon, 2002-11-18 at 03:55, Alexander Larsson wrote:
> > On 15 Nov 2002, Alex Graveley wrote:
> >
> > Meta-data changes changing the actual file? Ick! That wouldn't be 
> > metadata
> > at all, that would be data.
>
> I don't agree at all.  You should be able to view and change the author
> of a Word document without having to know the format.  You should be
> able to look at the playing time of a .ogg without knowing how.  You
> should be able to tell the operating system to compress or encrypt a
> file without it effecting gnome_vfs_read()/write().

Yes, but I don't think that belongs at the same layer and with the same 
API as attaching emblems or notes.
> > I'd love to have a real metadata API in gnome-vfs, but I don't think 
> > it
> > can replace a real per-backend ioctl style operation. While for some
> > designs of metadata you might be able to hack it into doing backend
> > specific things that is really not what metadata is for.
>
> I don't agree :)  Can you give me some useful examples of ioctls in
> gnome-vfs?

Eject a cdda:// uri? Request or patch specific WebDAV metadata. Request 
a particular revision of a file from a cvs backend. Even crazy stuff 
like getting a camera mounted through the gphoto method to take a photo.
> Also, I really don't like the thought of a per-backend -anything-.
> Backends are singletons, and allowing changes to them from one 
> component
> that might easily break the behavior that another component is relying
> on is bad.

Clearly clients would have to be able to deal with backends not 
supporting particular ioctls just like they have to deal with some 
backends not supporting seek and tell.

> And I don't think it would be a hack to do ioctls through metadata.  I
> think it makes sense, and will reduce APIs that will essentially 
> overrun
> each other in logical purpose.

NO NO NO.

(Dead) metadata should just be stuff thats attached to a file - we 
should have an implementation for modules that don't support storing 
metadata "near" the file that saves it in a ~/.something/ - just like 
Nautilus does right now. Overriding a simple get/set API to do clever 
things with particular key values is a bad bad thing. Bad. :)

I don't think having an extra API for a fundamentally different class 
of operation is wrong - I think its the right thing to do. If I can 
ever get a build working under this silly MacOS X I'll hack something 
together.

Ian