Re: ORBit (was Re: * mico)

[Elliot Lee <sopwith cuc edu>]

On Tue, 24 Feb 1998, Phillip Dawes wrote:

> It should be just a case of re-compiling the idl providing that both
> orbs support the same standard features, and we don't deviate from those
> standards. The problem is that mico doesn't support other language
> bindings than C++ and Java, and I think Elliot is musing over whether
> it's worth his time to develop C bindings for mico when we may end up
> coding our own 'C' orb with the gimp lot anyway.

(I think Mico is C++-only - I don't remember hearing that it did Java)
I've got C bindings almost ready for others to look at, but it is a
suboptimal solution - we need to do things the "right way" before chasing
after the god of rapid development :)

> I still think it'd be better as a short term solution to use omniorb for
> C and C++ bindings. Mico uses dii/dsi for its C++ bindings, and this is
> a real performance hit compared to omniorb. Just take a look at the
> stubs that the idl compiler knocks out to see what I mean.

Mico-C is going to be a short-term solution in any case (I hope to be
putting it into the CVS mico today, BTW)  We do not need optimum speed -
we just need something that works so that the developers don't get stuck
waiting for a CORBA solution.

> The other issue is objective C. This is Elliot's favourate
> 'close-to-the-metal' oo language, and AFAIK we're a bit dubious about
> getting that to link with a C++ orb.

ObjC is in my mind, yes, but I'm also concerned about guile, python,
perl, and all those other languages that tie in to C much more easily than
they do to C++ (I think you have to basically provide a C interface to the
C++ stuff, right?)

-- Elliot					http://www.redhat.com/
"The obvious mathematical breakthrough would be development of an easy way
to factor large prime numbers." -- Bill Gates from "The Road Ahead," p. 265.