Re: Towards better OAF/Bonobo integration

[Rodrigo Moya <rodrigo gnome-db org>]

On 28 Jul 2001 17:46:45 -0700, Maciej Stachowiak wrote:
> 
> For some time Michael Meeks and I have been discussing ways to make
> OAF and Bonobo more closely integrated.
> 
> One key step that we feel would improve the consistency of the
> platform is to make all of OAF's IDL interfaces (most particularly the
> public Factory interface) inherit from Bonobo::Unknown. This is also a
> critical step to developing a future public CORBA API to OAF
> activation, another goal Michael and I agree on.
> 
> In some ways, the best approach to achieving tight integration would
> be to merge the two modules; it really does not make that much sense
> to separate activation from the rest of the component model. However,
> Michael and I are right now unsure of our ability to work well
> together within the space of a single module, given some of our past
> disagreements.
> 
> So after some discussion I came up with this plan, which we believe
> would largely avoid the potential for massive argumentation while
> delivering many improvements to the platform. I think the plan
> outlined below is pretty good, and Michael said he would consider it
> over the weekend. He asked me to mail a write-up of the proposal to
> him and gnome-components-list.
> 
> Without further ado, here's the plan:
> 
> * We would Bonobo::Unknown IDL interface from the libbonobo module to
> the oaf module.
> 
> * The relevant GObject-based server and client convenience APIs would
> remain in libbonobo.
> 
> * I would promise that I (or any of my successors as OAF maintainer)
> will never change the Unknown interface without the express permission
> of Michael (or his successor as Bonobo maintainer). As far as I know
> the only proposal even on the table to do this is Darin's lease idea,
> and that definitely needs consensus before it goes in.
> 
> * All of OAF's IDL interfaces, public and private, would be changed to
> inherit from the Unknown interface.
> 
> * All of OAF's IDL interfaces, public and private, would be moved into
> the Bonobo:: namespace.
> 
> * OAF would be renamed to bonobo-base to recognize it's role as part
> of the Bonobo component model.
> 
> * I'm not certain about this, but perhaps OAF interfaces that pass
> around CORBA_Object's could be changed to pass Bonobo_Unknown's. I'm
> not sure what level of breakage vs. benefit this would cause just yet.
> 
> 
> * Longer-term, OAF would provide a public CORBA interface to querying
> and activation in addition to the current C API (and perhaps someday
> the C API might be deprecated, who knows).
> 
> 
> What will this mean for projects that use OAF but not Bonobo? Probably
> not that much. You won't have to change your porject to depend on
> libbonobo if you don't absolutely want to (although libbonobo provides
> many useful facilities which are highly recommended).
> 
> What does this mean for projects that currently use Bonobo? You'll
> benefit from more API consistency, tighter integration, and more
> reusability for the GenericFactory interface, among other things.
> 
> Comments, anyone?
> 
I really think this is a good idea

and yes, just one comment, and sorry for insisting, but, what about remote object activation?
AFAIK, it does not work yet, so I think this OAF/Bonobo integration
could be the right moment to think about this. Remote object activation
is very important for a component system,
and this is, IMO, what GNOME's component system is missing.

The other day, talking with some friends, I learnt that the "agreed
upon" (supposedly this was said by Elliott) solution for this was to use
rsh to connect to the remote system and then start an oafd on that
machine. I really think this solution is not very good.

So, what about having a second oaf daemon, integrated in inetd, which
listens to a pre-established port for remote oaf's?
I don't know too much what would be involved in the communication
between the remote oaf's, but I suppose the work to do it would be the
same in the rsh-case than in the inetd-service case

cheers

-- 
Rodrigo Moya <rodrigo gnome-db org> - <rodrigo ximian com>
http://www.gnome-db.org/ - http://www.ximian.com/