Re: ioctls for gnome-vfs

[Alex Graveley <alex ximian com>]

Hi,

On Mon, 2002-11-18 at 11:11, Alexander Larsson wrote:
> On 18 Nov 2002, Alex Graveley wrote:
> > 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.

What sort of filesystem semantics?

I don't think there is a better place.  You are already describing the
content of files because the mime-database and mime-snooping code is
part of gnome-vfs.  Why not take it to the next level and describe the
attributes of a type of file and allow them to be modified?  As long as
it is plugin-based, like the rest of vfs, I don't see a problem.

And I think having content metadata at the gnome-vfs level will also
allow gnome-vfs to get some really interesting search capabilities.

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

gnome_vfs_set_metadata ("printers:///myprinter/job1", 
			"print-status", 
			"paused");

How would doing this with an ioctl make it any clearer?

Now, what if you want to set double-sided printing, or orientation, or
some of the other umpteen-million printing options?  These seem like
metadata to me, but maybe not to someone else.  So now I have to think
about which API to use.  Will this named-option be considered an action
on the file or an attribute of the file?  Well, print job options seem
kinda like both.  

I think it will lead to confusion/annoyance to have two APIs, where the
distinction between them cannot be clear.

(Btw, we've also talked about this, and its a bad idea.  Printer queues
do not map well enough to a file-system.)

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

Understood, but the way you talked I thought you also wanted the ability
to set something global to a given method.

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

How will having an ioctl help this at all?  Not only will you have
namespacing for ioctls and for metadata, but you will have to know when
to use one and not another for a given ioctl or metadata call.

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

Or, URIs. :-)

-Alex

-- 
 on the canvass of life, incompetence is my paintbrush.