Re: [INTERFACES] ORB API

On 16 Nov 1998, Aleksey Demakov wrote:

> "Taral" <taral(at)cyberjunkie(dot)com> writes:
>
> > It appears that the C/C++ API for ORBs is very well defined. However they
> > are (especially in the case of pseudo-objects) not simply related. If we are
> > to support multiple ORBs, we will have to have a C to C++ thunking layer
> > somewhere...
>
> I'd suggest to support only one CORBA implementation in the PostgreSQL
> itself. It's IIOP that supposed to let different implementations to
> interoperate.
>
> I believe that ORBit is the best candidate, though it's not yet
> complete and its ability to interoperate with other implementations
> is to be proven. But unlike others it doesn't require egcs or
> OS thread support (omniORB). It is intended for real work, not
> for education (mico). It is in active development wich we can
> join to.

PostgreSQL's preliminary Corba support will be based on mico,
*mainly* because it is the only one that is 2.2 compliant...the others are
all stuck at 2.0...or incomplete (orbit)...

The design model for this, as for other parts of PostgreSQL, is
such that altho the initial design will revolve around mico, as the others
become 2.2 compliant, they will then become the choice of the person
compiling as to which one they want to use.

This isn't an overnight project, this will take several months to
implement, and will most likely be the trigger for a 7.0 release. By
starting the development off using mico as a basis, we are implementing a
2.2 model using a 'generic hook' method such that allowing ppl to use
ORBit or OMNIorb or any other implementation will be simply a matter of
modifying one central include file to map between libraries, as
required...once the others catch up to mico...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org