Re: Why Bonobo???

[Michael Meeks <michael ximian com>]

Hi Joachim,

On 17 Aug 2001, Joachim Rosskopf wrote:
> > What makes you think bonobo is appreciably slower than plain CORBA?
>
> I think one think that make bonobo signifcat slower is the bonobo
> moniker and property bag mechanism which produces a huge overhead of
> remote function calls.

        Um - well, they only use remote IPC if the interface /
implementation are in a remote process; if this is the case - it's hard to
see how you are going to communicate across the process boundary without
'remote function calls'. Perhaps a shmem segment ? :-)

        Anyhow - much of bonobo - including incidentaly all the common
monikers are implemented in shlib components which once linked in should
be extremely fast - although there is still room for optimizing liboaf so
it doesn't have to go out to the remote server to get references to local
shlib factories.

> > Seems to me the CORBA marshalling accounts for nearly all the
> > overhead, even when using ORBit in local mode.

        There should be no CORBA marshalling in the local case, also much
slowness is often caused by broken networking setups - can you run an
strace on what you think is slow $ strace -ttt ./foo and have a look at
the log to see what's taking the time.

> The overhead is not my main issue. I simply want to know what
> improvements does bonobo bring to me. Is the development easier or the
> are there any additional CORBA Services like a NamingService or a
> DII???

        Ok - so an activation framework (oaf), which is easy to use,
flexible and powerful. An embedding infastructure to allow you to make GUI
components easily. But the most valuable thing ( which makes CORBA
interface construction so much easier ) for you is probably BonoboXObject.
Without BonoboXObject CORBA interface implementation is a royal pain in
the backside and extremely verbose. While BonoboXObject is still somewhat
verbose - it is minimal, and integrates with the Gtk+ object system rather
nicely.

> But thank you for the fast reply. Much better than on the evolution
> mailing list... they don't post my message anyway *g*

        :-) well - I hope we can help you create a nice solution.

        Regards,

                Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot