Re: automatic method chaining the "right" way

[Ben Martin <monkeyiq users sourceforge net>]

Warning, email looking at solutions relative to libferris. I post mainly
in the interest of everyone gaining from knowing how other folks solve
the same problems.

On Sat, 2002-09-14 at 12:58, Ian McKellar wrote:
> On Fri, 2002-09-13 at 10:42, Shahms E. King wrote:
> > I'm assuming that URI chaining should be handled automagically by
> > gnome-vfs for supported MIME types (rather than, say, Nautilus or
> > another end-user app), and trying to get some opinions on the "right"
> > way to do this.  It seems this information is probably best specified in
> > the MIME information/metadata for the file so that it can be queried by
> > an application in someway, but also that an "open_directory" call on a
> > file that has chained methods will simply "do the right thing" at the
> > GVFS level.  
> > I'm tired of reading people complaints about this not working in
> > Nautilus, and I'd like to do something about it, but I'm not sure where
> > to start (and the MIME/metadata API is currently in flux, but I don't
> > know the intended direction or scope of the changes, so I'm at a loss
> > for how to begin/proceed).
> 
> Man, this is a real bitch of a problem. I've been thinking about this
> for over two years. Like you pointed out in reply to my "capabilities"
> rant GnomeVFS should expose to an application that a tarball supports
> directory operations and should "magically" handle invoking the tar
> method. Well, I think so anyway. I made chained methods work while I was

Yeah, this is what I also think and infact how libferris handles
chaining (or overmounting as I call it).

> at Eazel but nobody ever came up with a decent UI. The problem was this,
> when a user opens an image file they can use the "Open with..." menu to
> switch between EOG, Nautilus' internal viewer and other future
> components designed to show images. With chained methods the way they
> work currently, the act of "activating" a chained URI will change the
> URI from file:///path/to/file.tar to file:///path/to/file.tar#tar:/ -
> And then they won't be able to switch to another view (such as a guitar
> component or something like that) because as far as the application is
> concerned this isn't a tar file, its a directory.
> 
> Once we have some kind of has_directory_ops capability exposed through
> GnomeVFS we can try to work out how to allow methods to provide extra
> operations for resources of a given type.
> 
> The whole thing is quite tricky because once you remove the magic
> character from the URI its hard to work out which parts of the URI are
> handled by which components. For example with this URI:
> file:///path/to/file.tar/foo/bar/baz.txt, its not clear that file.tar is
> a tarball rather than a directory till you try to look for the local
> file /path/to/file.tar/foo/bar/baz.txt and find its not there. Sure you
> can walk up the URI doing stats, but this will suck really badly for
> remote filesystems where even small operations are expensive.

For something like this libferris will walk doing stats() and then at
the .tar will switch to using the tar overmounting fs. For remote
filesystems I usually alow resolution of fake paths and then test if the
result is valid. (at the moment I only allow mounting .tar.gz files on
remote servers via the ssh libferris module, so the issues are handled
as the local case by the remote libferris code).


> 
> So I too am at a loss. I would love to hear anyone's ideas about this.

Well, I have found the same gotchas along the way. My solution is to
make the mimetype EA always the type for that object, so a tar file
would have the right tar mimetype. If a file can be mounted like a
directory then just read()ing it will do that for me in libferris. I
have also defined many other EA, "is-dir" and a method to "guess" if a
context has children. The motivation for the guessing is that by default
there are children, and if the underlying FS module can test if an
object has children without reading them then it can quickly return a
result. The guess is only supported if the data source has a quickish
method (like a stat()) to test for possible child presence.

> This would be really cool to support well. AFAIK KDE don't support
> chaining at all, they just defined a magic tar:// uri scheme that only
> works for local files. I think thats a cop-out.
> 
> Ian
-- 
-----------------------------------------------------
http://witme.sourceforge.net/libferris.web/