Re: ioctls for gnome-vfs

On 18 Nov 2002, Alex Graveley wrote:

> On Mon, 2002-11-18 at 03:55, Alexander Larsson wrote:
> > On 15 Nov 2002, Alex Graveley wrote:
> > 
> > > Hi,
> > > 
> > > On Fri, 2002-11-15 at 15:09, Joe Shaw wrote:
> > > > I'm not so sure.  Maybe it's just the terminology, but "metadata" to me
> > > > means any arbitrary information layered on top of files, probably
> > > > persistent.  Image thumbnailing seems like a good use of metadata to
> > > > me.  
> > > > 
> > > > This seems more like additional parameters on the method itself...
> > > > things like setting HTTP headers for a specific request or passive mode
> > > > on FTP.
> > > 
> > > I think it depends completely on the metadata being twiddled.  For
> > > instance: idealy we would want metadata stored on an mp3 and prefixed
> > > with "id3-tag:" to be stored in the id3 section of the file itself. 
> > > Just as likely is setting headers in an http transfer, before a read or
> > > write; in this case the meta-data should only be available for setting
> > > on an open file handle, and not on a URI.
> > 
> > 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().  

I don't like this at all. It heavily affects all sorts of filesystem 
semantics in ways people will not expect. It also puts way to much 
domain-specifc knowledge in the vfs. Let us not make the filesystem layer 
know the layout of word documents.
> > > Also an issue for me is the that i can't think of any good reason for a
> > > file-control api.  We don't expose sockets or file descriptors.  Ans the
> > > example that alexl posted is certainly metadata and not an ioctl, since
> > > the attribute is associated with a file and would presumably remain for
> > > its lifetime.
> > 
> > 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?  

A typical example that we discussed once was a cups-backend for gnome-vfs. 
You can list jobs on different printers easily. But if you want to pause a 
job, how to do you do that? 
> 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. 

Eh? I don't understand this at all? In what way do ioctls make the 
backends not be singeltons? ioctls work on files, not on the backend 
> 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.

It will increase the amount of code and complexity in gnome-vfs, and it 
will make us rely more on magic namespacing.
> > Metadata is auxilliary information about the file, some metadata is 
> > already stored by the os, such as file modification dates, permissions 
> > etc. Others (as used by nautilus) are custom icon, icon position, icon 
> > stretch factor, etc.
> Yup, and it will rely on good namespacing to know which is which, and
> whether what you are setting will effect the operating system, nautilus,
> or the file's content itself.

Sounds like monkiers.

 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a gun-slinging playboy firefighter in drag. She's a disco-crazy tomboy 
soap star who dreams of becoming Elvis. They fight crime! 

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