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

[Maciej Stachowiak <mjs eazel com>]

Michael Meeks <michael ximian com> writes:

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

I doubt it. I think the changes would be fairly minor. I can even
vaguely imagine ways to do it that don't involve changing the module
interface at all.

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

It could be, but I don't much see how that would help add this feature.

>         There is no need for a fast path optimization with in-proc moniker
> implementations I would suggest.

It would likely reduce copying. 

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

Indeed, it would be nice for everything to be a component in the
future, but I think basing gnome-vfs on today's Bonobo would result in
significant performance losses from extra memory overhead and
copying. It's possible that won't be the case with an UNOfied Bonobo,
but this sadly won't be available in stabilized form until after the
GNOME 2.0 library code freeze.

I also note that you specifically discouraged hackers from making
libgnome/libgnomeui/etc depend on Bonobo so that bonobo churn would
not impede those libraries from meeting the freeze. I think the same
argument aplies to gnome-vfs, especially given that all the gnome-vfs
dependency stuff would be a new feature.

Of course, I am not the maintainer of gnome-vfs, so this opinion is
purely advisory in nature.

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

Clearly some future world is far more component-oriented; alas that we
do not yet live in those exciting times.

-- 
Maciej Stachowiak
Eazel, Inc.