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

> > Well, specifications for language mappings exists, but each 
> ORB needs 
> > its own implementation. Because GNOME chose to write its own ORB 
> > (ORBit) there are still very few language bindings for it. 
> In fact I 
> > don't think there are any that are complete or stable, and the 
> > complication of CORBA means that it's unlikely that they will be 
> > finished any time soon.
> I don't believe this is correct, my understanding is that a 
> number of fully CORBA-2.2-compliant ORBs are out there.  And 
> I don't think there's much of interest in CORBA-2.2 that 
> ORBit2 doesn't do.

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.

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

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

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

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

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 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]