GCOM, was Re: Communicating with MICO

[Duncan Grisby]

In article <slrn8a4h6i.uhd.kc5tja at garnet.armored.net>,
 Samuel A. Falvo II <kc5tja at garnet.armored.net> wrote:

[...lots of interesting COMishness...]

>So the "sluggishness" that CORBA has amassed a reputation for is not the
>fault of the spec, but of the individual ORB and B/POA APIs.  However, the
>APIs do add an unnecessary layer of complication to the development of any
>standards-compliant ORB.  And 2.3 just makes things worse.

I'm interested in this "sluggishness". Do you have any experience or
references to suggest that CORBA is sluggish in comparison to COM?
Some CORBA implementations are quite slow (most notably Orbix), but
others are not. I've just done a web search, and I can't find _any_
speed comparisons of CORBA and COM; all of the COM/CORBA comparisons
use other criteria. There are plenty of performance comparisons
between different CORBA ORBs.

As for API complexity, I agree that the CORBA APIs are unnecessarily
awkward. However, the often-cited paper by Emerald Chung et al.

  http://www.research.microsoft.com/~ymwang/papers/HTML/DCOMnCORBA/S.html

implies that using COM from C++ is far more of a burden. I have no
experience of COM programming myself, so I don't know how accurate it
is.

Anyway, to get back on-topic for the newsgroup, using CORBA from
Python cuts out the vast majority of the API ugliness. CORBA lets you
do some fundamentally complex things, though, so there is bound to be
some complexity in the API. For most things you can do with CORBA, the
Python code is extremely simple. I assume the same is true for
Python's COM interface.

Do you have a reference for GCOM?

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --