Re: [GNOME VFS] Re: GUADEC Issue discussion summary ...

[Michael Meeks <michael ximian com>]

On 18 Apr 2001, Maciej Stachowiak wrote:
> OK, so the requirement would be for gnome-vfs to expose the
> filter-oriented modules (gzip, tar, etc) in a way that lets you apply
> them to an arbitrary data stream and not just chain them to other
> gnome-vfs modules.

        Yes, quite right. This would need some fairly significant changes
to the way modules, URIs and handles interact I imagine. Still, in gnome  
2.0, now that we have GObject, it would be possible to make gnome-vfs more
explicitly OO which would be nice.

> I think it should not be hard to design an API like that and it
> doesn't necessarily require depending on bonobo. At the same time, the
> vfs moniker could do a fast-path optimization for things like      
> http://foo.bar/baz/quux.gnumeric.gz#gzip: where it knows it can handle
> multiple parts of the chain directly.
  
        There is no need for a fast path optimization with in-proc moniker
implementations I would suggest. However, I hope that the future for the
gnome-vfs should lie in a set of clean IDL interfaces, preferably
extending / expanding the Bonobo/Stream interface - though how best to do
that needs thought.

	There is really not room in the Gnome world for this tension
between large C APIs and their CORBA equivalents.

        Of course, I can understand your reluctance to depend on bonobo,  
but we could have a separate module as you suggest - but I think module   
proliferation is rather sub-optimal.  

> BTW, I don't think you really want "vfs:" in a moniker ever, anyway;

        Quite,

                Michael.

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