Обсуждение: ORB API

Поиск
Список
Период
Сортировка

ORB API

От
"Taral"
Дата:
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


Re: [INTERFACES] ORB API

От
Aleksey Demakov
Дата:
"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

Re: [INTERFACES] ORB API

От
The Hermit Hacker
Дата:
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


RE: [INTERFACES] ORB API

От
"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
> 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


Re: [INTERFACES] ORB API

От
"Thomas G. Lockhart"
Дата:
> > 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

RE: [INTERFACES] ORB API

От
"Taral"
Дата:
> 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


Re: [INTERFACES] ORB API

От
Aleksey Demakov
Дата:
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