Re: ioctls for gnome-vfs

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

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.


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


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