Re: [GNOME VFS] - where to put bonobo module...

[Maciej Stachowiak <mjs eazel com>]

Michael Meeks <michael helixcode com> writes:

> Hi Maciej,
> 
> On 28 Nov 2000, Maciej Stachowiak wrote:
> > Why do you think it should be in gnome-vfs rather than in bonobo? 
> 
> 	Because bonobo without X is a core technology, at root it is on
> the same conceptual layer as CORBA. It does not seem sensible to add a
> dependency to bonobo that is not neccesary.

gnome-vfs is also a core technology; at root it is on the same
conceptual layer as the filesystem calls in libc. Similarly it does
not make sense to add a dependency to gnome-vfs that is not necessary.

> > That would make it impossible to, for instance, add a moniker
> > implementation to Bonobo that uased gnome-vfs
> 
> 	Monikers do not have to be based in bonobo; they are fully
> extensible and can be installed from anywhere, as can storage modules. So
> this in no way militates against a vfs moniker.

I don't think there should be a "vfs:" moniker. That would be clearly
lame. I think there should be "tar:" and "http:" and "ftp:" and
"gzip:" and "nfs:" and "gphoto:" and so on monikers that use
gnome-vfs, allowing monikers to provide a superset of the namespace
provided by gnome-vfs (ideally these should be provided by a single
server since the implementation would be nearly identical - just use
the vfs storage module to open a stream and other than that operate
just like the "file:" moniker). 

[Side note to people who write monikers that duplicate gnome-vfs
functionality - can you please use the same protocol name and syntax
for things like "tar:" and "gzip:" so the gnome-vfs and moniker
namespaces are not gratuitously different?]

I'm also not so sure about the "fully extensible"; many of the
monikers currently in bonobo have their IIDs hardcoded in
bonobo-moniker-util.c, meaning there's no way they can be replaced if,
e.g., I wanted an http moniker that did not hardcode EBrowser as the
HTML control but rather followed some sort of user preference, or used
an image viewer instead of a browser to view images, or other crazy
things like that.

(Interestingly, the http moniker in bonobo hardcodes an IID for a
control and a name for a storage module neither of which are provided
with bonobo, meaning that the http moniker is broken as shipped unless
you install gtkhtml, meaning the circular dependency is still there,
even if it's not a build-time dependency; of course, it will also
gratuitously fail on a request for any interface but Stream and
Control so maybe it's just not done enough yet to consider these kinds
of issues).

> > or indeed to make any module that bonobo depends on use gnome-vfs, or
> > we'd run into circular dependencies. Since Bonobo depends on
> > gnome-libs and gnome-libs will depend on gnome-vfs for GNOME 2, this
> > would actually become a problem in practice.
> 
> 	For Gnome 2. Bonobo will probably need to be fully split bonobo
> and bonobox; The X stuff might depend on gnome-libs, the non-X stuff only
> on glib. The non-X stuff contains the moniker and stream handling code.
> 
> 	The solution in the short term is perhaps then to create another
> module that implements the gnome vfs storage module and possibly the
> moniker, that is if anyone is actualy interested in fixing the mess.
> 

I am vaguely motivated to fix the vfs stream/storage implementation in
Bonobo, but I am definitely not motivated enough to create and
maintain a whole new package for it. So let me know if you'd take a
patch to fix the one in Bonobo and re-enable it in the build,
otherwise I'll merge whatever I can to the nautilus version and
provide a patch to remove the copy in Bonobo entirely.

Regards,

Maciej