Re: automatic method chaining the "right" way

["Shahms E. King" <shahms shahms com>]

> 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:
Well, one way to deal with a small part of the problem is application
side, associating a GnomeVFSURI (or some application specific state
structure, if we're just using gchar*) with enough information to know
the "full" path and simply display the partial ones.  The context can be
smart enough to know and use the "real" URI for variations of that URI
without the chained method(s) and use that when calling gnome-vfs.


> 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.
> 
Well, we don't have to stat anything whose pathname does suggest a
certain mime-type, in this case it would math *.tar and that mime-type
information -- gained from only a string match, not a full stat yet --
would give the has_directory_ops flag. Possibly an externally installed
application handles this mime-type and has a gnome-vfs plugin for it,
and has registered itself as such, or one of the gnome-vfs stock modules
can handle it.  You can then stat that limited number of files to
determine the real mime-type and proceed with that?

There is also the possibility of just failing on directories that aren't
local, it's not ideal, but at least it gets the behavior working for the
common case (I'd think).  For the remote locations it might even work to
only check if we get a file not found error, odds are good that most
people chaining multiple archives from a remote size are going to be in
for some slowness anyway just from all the unpacking and searching going
on in the archives.  Perhaps I'm underestimating the number of people in
this situation.  The gnome-vfs calls themselves could cache the stats
(except in cases of file not found and possibly some others) to reduce
round trips for people poking around inside of an archive on a remote
site, the initial lookup will be slower, but so will file access because
we'll have to download, at least part of it, to open it and chain them
anyway.

Am I overlooking something, comments? 

--Shahms

Also, I was looking at freedesktop.org the other day and came across the
Shared MIME spec, and was wondering what, if anything was going on in
that area?


> So I too am at a loss. I would love to hear anyone's ideas about this.
> 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