Re: automatic method chaining the "right" way

[Michael Meeks <michael ximian com>]

Hi Ian,

	I'm having problems understanding the problem here:

On Sat, 2002-09-14 at 03:58, Ian McKellar wrote:
> 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.

	OK;

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

	A 'guitar view' of a tar file ? :-) surely this is 'simply' a matter of
building the 'View As' list from two sources; registered operations on
'*.tar' and whatever other generic operations we can do to that file; -
distinguishing them such that the URL we pass to the new view changes
our locations [ by removing or appending #tar:/ ] as we switch ?

	Surely not impossible to do; of course another way round is to go 'up'
a directory, and right click on the folder. Then again - surely it's not
likely for too many things to be registered vs. tar.gz ?

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

	What's wrong with the existing directory operations on the method
structure ?

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

	Sure;

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

	Clearly I don't understand the problem; my view of the real problem
with archive handling is an efficiency based problem - such that I'm
concerned about how we handle the (unfortunate) need to unpack
potentially large archives, and then use them from multiple processes.
This seems to militate in favour of a separate 'VFS' daemon, which we
could do very neatly with CORBA :-)

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot