Re: GNOME & KOM/OP

[Phil Dawes <philipd parallax co uk>]

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.


Anders W. Tell wrote:
> 
> Phil Dawes wrote:
> 
> > I'd like to venture the following opinions:
> >
> > 1) We don't need COM. CORBA replaces COM. There is NOTHING you can do in
> > com that you can't do with corba. (I have yet to be proven wrong on
> > this. Please feel free flame :-).
> 
> Ill bite on this one ;-)
> Corba has currently on flaw and that is that you need an ORB beween objects
> which means a gross overhead when doing interprocess call beween object.
> There are some work going on with Collocation - corba between objects in same
> adress space -
> but the Corba spec says that the call arguments should be deliverd to the orb
> before they are
> sent to the callee.
> This means that Corba is many times slower than a COM call which is the same as a
> c++ virtual call.
> 

In the current 2.2 spec, if you want to implement all the features then
this is true.

However there is a new 'real time' corba specification on the horizon
from OMG which effectively allows the circumvention of POA Managers and
interceptors, which AFAIK does allow true object collation as you
mentioned. 

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.

There are problems with this approach (which COM also suffers from)
since the client effectively controls the object, including its
lifetime. Reference counting is all fine and dandy, but it requires the
client to be well behaved. Providing all parties are happy with this
state of affairs then there is no problem though.

The other main difficulty in corba with collated stubs is how to handle
multiple-inheritence in the C mapping. If a vtable system is to be used,
then the C language mapping *must* be changed to allow the casting of
child object references into parents, since the vtable pointer has to be
modified. This is not a problem for single inheritence, or C++ which
implicitly mangles MI pointers anyway, or COM for that matter due to its
QueryInterface mechanism. According to Richard Grimes (author of Wrox's
Professional DCOM - quick name drop there) this was the primary reason
that interface MI was dropped - not that 'fragile baseclass' rubbish!


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

> Not all object are therefore good candidates for Corba.Smaller and faster objects
> can be more efficiently
> implemented in COM.
> 

We'll see ;)


> I myself is working in a model i call GCOM where the DCOM part is replaced Corba
> but
> the Component Binary interface is still there and also the dynamic class/library
> loading facilities.
> So its a combination of Corba with selected part of COM core.
> 
> See first diagram for an overview.
> <http://www.toolsmiths.se/components/html/library.html>
> 

Thanks for the URL - I hadn't seen that page before.

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.

Cheers,

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.