Обсуждение: ORB API
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... The analysis continues. Taral
"Taral" <taral@cyberjunkie.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. Aleksey -- Aleksey Demakov avd@gcom.ru
On 16 Nov 1998, Aleksey Demakov wrote:
> "Taral" <taral@cyberjunkie.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@hub.org secondary: scrappy@{freebsd|postgresql}.org
> 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. But does it fully support the basic CORBA 2.2 API *right now*? The point of using mico was that we can easily switch ORBs later on since the 2.2 API is so specific. Example: omniORB does not use the 2.2 perform_work()/run() functions, but instead has an extension to the impl_is_ready() function. Although their implementation is valid under 2.0, it is *not* valid under 2.2. Taral
> > 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
Someone might want to try implementing, as an experiment and demo, a
Corba packaging of Postgres using libpq on the _server side_. That way,
we can demonstrate functionality, interfacing, and performance without
ripping into the backend directly until we understand some of the
issues.
So:
app (applix?)--corba stub--(otw i/f)--corba server-- \
--wrapper code--libpq--(postgres socket i/f)--backend
We might want some real wrapper code to make it a real object-oriented
API to fit best with Corba.
- Tom
> Someone might want to try implementing, as an experiment and demo, a > Corba packaging of Postgres using libpq on the _server side_. That way, > we can demonstrate functionality, interfacing, and performance without > ripping into the backend directly until we understand some of the > issues. I was going to get a stable interface, and then implement part of that interface using libpq... less code waste :) Taral
Sorry, I don't know whether I'm right crossposting this to two mailing lists. I hope that ORBit guys could comment better on this post [this is discussion about choosing ORB for PostgreSQL]. Aleksey "Taral" <taral@cyberjunkie.com> writes: > > 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. > > But does it fully support the basic CORBA 2.2 API *right now*? The point of > using mico was that we can easily switch ORBs later on since the 2.2 API is > so specific. > > Example: > > omniORB does not use the 2.2 perform_work()/run() functions, but instead has > an extension to the impl_is_ready() function. Although their implementation > is valid under 2.0, it is *not* valid under 2.2. > > Taral > > > > -- Aleksey Demakov avd@gcom.ru