Re: GNOME & KOM/OP

["Anders W. Tell" <anderst toolsmiths se>]

Elliot Lee wrote:

> >> Well, the underlying mechanism for all of this is CORBA, so the ORBit people
> >> can probably answer authoritatively.  Elliot seems to think that he can do
> >> CORBA calls in the same address space without mashalling the parameters, which
> >> would let you get pretty close to the same speed as shared libraries.  I'll
> >> let someone else answer this one further.
> >
> >I know nothing about CORBA, but this is certainly the case in COM.  The
> >only real overhead incurred in accessing an in-process COM object is the
> >overhead of the single function call required to obtain the interface
> >you're after.  All subsequent calls on the interface are as fast as a
> >normal virtual function call.
>
> The problem is that with CORBA, you either need to define a custom object
> adapter, or you have to add indirection in order to take care of the POA
> processing. If you make a few restrictions on how people can use the POA
> for these in-process objects, you don't have to do either, which makes it
> a fairly reasonable thing to do.
>
> While this feature is on the long-term (i.e. AFTER version 1.0 :) TODO
> list for ORBit, I really don't think CORBA was intended for a lightweight
> per-program object model. Use GtkObject for intra-program objects, and
> CORBA for inter-program ones.

Agree here with you here that Corba is not (yet anyway) suited for intra process
communication
small and fast objects.

However I think all this is solvable if a Component Binary Interface is slided beneth
the Corba code.
The CBI takes care of the indirection, also between C and C++ object.

I made some diagramsabout the idea.
<http://www.toolsmiths.se/components/html/library.html>

/Anders