RE: Java/Bonobo and inter-orb communication [was: shipping Vera w ith 2.4]

[Bill Haneman <bill haneman sun com>]

On Mon, 2003-03-03 at 17:14, Murray Cumming Comneon com wrote:

> I meant that there are no complete or stable language bindings for ORBit.
> ORBit2 doesn't really do C++ yet and that's significant. If we could just
> use a separate ORB then I'd be very happy and stop working on orbitcpp.
> Maybe that is possible for the simple IPC stuff. I don't think it's possible
> for Bonobo, which seems to be tied to ORBit.

I don't think so, based on my own experience, but so far I've only
implemented Bonobo::Unknown and a bit of PropertyBag in Java, I haven't
done all of Bonobo::Component yet.  I don't anticipate any serious
issues however.

> 
> > > Personally I do wish we could use CORBA for all IPC but I recognise 
> > > these practical problems:
> > > - CORBA in C is ridiculously difficult. GNOME uses C.
> > > - ORBit2, being a new ORB, has no other usable language bindings, 
> > > particularly no complete C++ bindings for use by KDE.
> > 
> > As has been noted, ORBit2 fully supports Inter-Orb communication.
> 
> Cool. Is that easy? I am ignorant.

It's as easy as turning on ORBTTOPIPv4=1 in .orbitrc :-)

> > > . I suspect that this is part of the
> > > reason that we could never use a different CORBA ORB (maybe 
> > one with 
> > > C++
> > > mappings) to do Bonobo programming. 
> > 
> > Not at all true; for instance there is quite a bit of Bonobo 
> > programming (both client-side, and implementations of Bonobo 
> > services) in Java in cvs module "java-access-bridge".  The 
> > Java bindings for Bonobo are especially nice, really elegant. 
> >  Of course the Java VM uses its own ORB, but it talks 
> > seamlessly to ORBit2 (thanks to a lot of debugging and 
> > testing by Mark McLoughlin and Michael, etc.)
> 
> That's really cool. It was my understanding that large parts of the Bonobo
> CORBA interfaces were not meant to be used directly. Maybe my time would be
> better spent pulling the sugar and IDL in Bonobo apart instead of trying to
> implement a C++ mapping.

I think the restriction on the IDL is only for 'bonobo-activation' and
not for "Bonobo" itself; (I suspect the confusion may be an unfortunate
side-effect of moving our activation stuff into the 'BONOBO' namespace).
I don't think Michael wants us to program directly to
Bonobo_ActivationContext or Bonobo_GenericFactory yet, but
Bonobo_Unknown.idl is fair game, as are all the IDL interfaces in
'libbonobo/idl' AFAIK.

Personally I want to keep lobbying for making the activation stuff
public too, since we need to use it from Java.  Michael, what will it
take to declare these stable?

> > Anyone who says Bonobo APIs are hard to program to 
> > (especially if they dislike Java ;)  should really give this 
> > a look, particularly the client-side code in the 'test' 
> > directory. [Note that there is some regression in the JNav 
> > client code at the moment due to the removal of a dependency 
> > on gnome-speech, to solve a circular dependency issue, but 
> > the sources are still valid.]
> 
> This could definitely give us some clues. Thanks. Roughly which Bonobo CORBA
> interfaces does this project use?

So far it uses Bonobo::Unknown and all of the Bonobo-derived interfaces
from at-spi, and the Bonobo-derived interfaces from gnome-speech.  We
will be needing to do Bonobo::PropertyBag stuff very soon, at least
client-side (which we think should be trivial) but we haven't
implemented PropertyBag server-side yet.  There are other folks actively
looking at implementing Bonobo::Component and Bonobo::Control, etc.

Of these, the at-spi interfaces are by far the most complex; the fact
that it works for them (including lots of callbacks, reentrancy, and
passing all kinds of arguments) gives me good confidence that
implementing all of Bonobo's IDL should be fairly straightforward.  The
main trickiness expected will have to do with native window
handles/physical embedding of windows, but we think that can be done.

> > In fact the addition of a complete implementation of 
> > Bonobo::Unknown in Java has already been discussed publicly 
> > and is planned very soon;
> 
> I think we also implement Bonobo::Unknown in C++ for libbonobomm so that
> people can implement Bonobo servers purely in C++. It's quite simple. The
> wrappers of existing servers don't use this.
> 
> > the implementation is already in 
> > java-access-bridge but it really needs to be split out into 
> > its own module so that the several modules that are already 
> > using Java Bonobo bindings can have a more rational dependency graph.
> 
BTW Gergo (who made the first attempt at this in gnome-1-X days) has
given his blessings to our calling it 'monkeybeans2'.  We found some of
the problems that were probably frustrating that initial implementation.

> Makes sense. Thanks for this. It is very enlightening for us C++ people,
> even though it doesn't help much for the whole D-BUS discussion. I hope I
> have time to investigate this further.
> 
> Murray Cumming
> murrayc usa net
> www.murrayc.com
-- 
Bill Haneman <bill haneman sun com>