Re: GNOME & KOM/OP

[Phil Dawes <philipd parallax co uk>]

Adrian Ratnapala wrote:
> 
> On Sun, 9 Aug 1998, Phil Dawes wrote:
> 
> > N.B. I've moved this topic to the Gnome-Components list (I expect Miguel
> > and Stephen get enough personal mail)- hope you don't mind.
> >
> >
> 
> > I submitted a back-of-a-cigerette-packet design for an orb mechanism in
> > orbit which would allow collation without polluting the user source code
> > (I think it's in the orbit doc directory). It involved passing options
> > to the idl compiler during stub creation which enabled collated stubs,
> > and then a veto system with the orb during the 'bootstrapping the object
> > reference' stage. If all parties agree (client, server and orb) then the
> > object can be collated in the client address space and left to talk
> > through a binary interface.
> Default should be to allow colation.  It's what you will want to do
> 99% of the time.  Just a hint.
> 

For desktop components, yes. However for inter-application
communication, not really. Also, you don't want to stop applications
from being scriptable by only providing collated stubs for your
components. However there's nothing to stop orbit from creating a
specialised fast interprocess connection (e.g. shared memory) for these
cases though.

> >
> > > You need a proxy which means that the size of an object grows.
> > >
> >
> > Yes, but you also need this in COM. QueryInterface has to be implemented
> > somehow. (What I meant by that was that there is no extra proxy code
> > needed by a corba collated stub than by a COM custom interface).
> >
> 
> > I want to do that same as you're doing with GCOM in corba with ORBit. I
> > want to enable C++, C and other compiled language objects to be able to
> > communicate at speed through a binary interface for inprocess objects.
> > Watch this space.
> 
> It seems pretty standard practice.  OmniORB (and I think Mico) handle
> it quite simply.  When the client asks for an object, what it could get
> the IDL generated stub which does the marshalling and all, or it
> could get the implementation itself (this will happen in the inprocess
> case).
> 
> They just have a little heirarchy somthing like
> 
>         TheInterface
>           /         \
>          /           \
>    TheInterface_impl  \
>                        \
>                   TheInterface_stub (or whateverit's, I forget).
> 
> The client asks the factory for a TheInterface object, and doesn't
> care if it gets a TheInterface_impl or a TheInterface_stub.
> 
> I assume you already know this though.
> 

Yes, but this only works for C++, and then only if the vtables match up
(i.e all components come from similar compiler implementations). 
We need to define the binary interface in C so that both C and C++
objects can support it.
I think the best way to do this is have the idl-c++ stub generator
generate the stubs in C, and then create an inline proxy C++ object
which maps the implementation to it - I've tested this approach with g++
and it worked without a hitch (and as fast as C++ virtual functions
since the mechanism is effectively the same). This does rely on knowing
the call signature of C++ operations though - I'm assuming that they all
stick a pointer to the object as the first argument to the operation...

Cheers again,

Phil.

-- 
_______________________________________________________________________
 Phil Dawes                               |   My opinions are my own
 WWW:    err.. temporarily non-existant   |   and nothing to do with
 Email:  philipd@parallax.co.uk           |      my employer.