pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedORB API
11+ messages / 5 participants
[nested] [flat]
* ORB API
@ 1998-11-15 07:24 Taral <taral@cyberjunkie.com>
0 siblings, 1 reply; 11+ messages in thread
From: Taral @ 1998-11-15 07:24 UTC (permalink / raw)
To: pgsql-interfaces@hub.org
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
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [INTERFACES] ORB API
@ 1998-11-16 05:13 Aleksey Demakov <avd@gcom.ru>
parent: Taral <taral@cyberjunkie.com>
0 siblings, 2 replies; 11+ messages in thread
From: Aleksey Demakov @ 1998-11-16 05:13 UTC (permalink / raw)
To: pgsql-interfaces
"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
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [INTERFACES] ORB API
@ 1998-11-16 05:36 The Hermit Hacker <scrappy@hub.org>
parent: Aleksey Demakov <avd@gcom.ru>
1 sibling, 0 replies; 11+ messages in thread
From: The Hermit Hacker @ 1998-11-16 05:36 UTC (permalink / raw)
To: Aleksey Demakov <avd@gcom.ru>; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [INTERFACES] ORB API
@ 1998-11-16 06:04 Michael Robinson <robinson@public.bta.net.cn>
0 siblings, 2 replies; 11+ messages in thread
From: Michael Robinson @ 1998-11-16 06:04 UTC (permalink / raw)
To: avd@gcom.ru; scrappy@hub.org; +Cc: pgsql-interfaces
The Hermit Hacker <scrappy@hub.org> writes:
> 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)...
You are aware, aren't you, that Mico has no support whatsoever for
interfacing to C code? If PostgreSQL will base it's preliminary support on
Mico, then all the interface development will have to be done twice: once
in C, and then a C++ wrapper to mediate between PostgreSQL and Mico.
>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...
I would recommend you look more closely into the role language mappings play
in the CORBA architecture, versus the role played by Inter-Orb bridges.
-Michael Robinson
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [INTERFACES] ORB API
@ 1998-11-16 13:23 The Hermit Hacker <scrappy@hub.org>
parent: Michael Robinson <robinson@public.bta.net.cn>
1 sibling, 0 replies; 11+ messages in thread
From: The Hermit Hacker @ 1998-11-16 13:23 UTC (permalink / raw)
To: Michael Robinson <robinson@public.bta.net.cn>; +Cc: avd@gcom.ru; pgsql-interfaces
On Mon, 16 Nov 1998, Michael Robinson wrote:
> The Hermit Hacker <scrappy@hub.org> writes:
> > 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)...
>
> You are aware, aren't you, that Mico has no support whatsoever for
> interfacing to C code? If PostgreSQL will base it's preliminary support on
> Mico, then all the interface development will have to be done twice: once
> in C, and then a C++ wrapper to mediate between PostgreSQL and Mico.
Actually, Taral pop'd into IRC yesterday all excited because he
found out that mico does have support for interfacing to C code...*shrug*
Taral? Comments?
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [INTERFACES] ORB API
@ 1998-11-16 13:45 Michael Robinson <robinson@public.bta.net.cn>
0 siblings, 0 replies; 11+ messages in thread
From: Michael Robinson @ 1998-11-16 13:45 UTC (permalink / raw)
To: scrappy@hub.org; +Cc: avd@gcom.ru; pgsql-interfaces
The Hermit Hacker <scrappy@hub.org> writes:
> Actually, Taral pop'd into IRC yesterday all excited because he
>found out that mico does have support for interfacing to C code...*shrug*
I stand corrected. I was following the CORBA feature matrix:
http://www.vex.net/~ben/corba/orbmatrix.html
There was a delay in my "pgsql-interfaces" subscription, so I missed Taral's
message. I'm now catching up from the archive.
-Michael
^ permalink raw reply [nested|flat] 11+ messages in thread
* RE: [INTERFACES] ORB API
@ 1998-11-16 15:29 Taral <taral@cyberjunkie.com>
parent: Aleksey Demakov <avd@gcom.ru>
1 sibling, 2 replies; 11+ messages in thread
From: Taral @ 1998-11-16 15:29 UTC (permalink / raw)
To: Aleksey Demakov <avd@gcom.ru>; pgsql-interfaces
> 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
^ permalink raw reply [nested|flat] 11+ messages in thread
* RE: [INTERFACES] ORB API
@ 1998-11-16 15:32 Taral <taral@cyberjunkie.com>
parent: Michael Robinson <robinson@public.bta.net.cn>
1 sibling, 0 replies; 11+ messages in thread
From: Taral @ 1998-11-16 15:32 UTC (permalink / raw)
To: Michael Robinson <robinson@public.bta.net.cn>; avd@gcom.ru; scrappy@hub.org; +Cc: pgsql-interfaces
> You are aware, aren't you, that Mico has no support whatsoever for
> interfacing to C code? If PostgreSQL will base it's preliminary
> support on
> Mico, then all the interface development will have to be done twice: once
> in C, and then a C++ wrapper to mediate between PostgreSQL and Mico.
Have you tried 'idl --no-codegen-c++ --codegen-c'? It doesn't yet support
arrays, sequences, and a few others, but it's there :)
> >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...
>
> I would recommend you look more closely into the role language
> mappings play
> in the CORBA architecture, versus the role played by Inter-Orb bridges.
Yes, it looks like eventually the ENTIRE backend will have to be written to
support CORBA directly, especially if we want to be COSS-compliant. See my
IDL postings for details.
Taral
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [INTERFACES] ORB API
@ 1998-11-17 03:14 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Taral <taral@cyberjunkie.com>
1 sibling, 1 reply; 11+ messages in thread
From: Thomas G. Lockhart @ 1998-11-17 03:14 UTC (permalink / raw)
To: Taral <taral@cyberjunkie.com>; +Cc: Aleksey Demakov <avd@gcom.ru>; pgsql-interfaces
> > 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
^ permalink raw reply [nested|flat] 11+ messages in thread
* RE: [INTERFACES] ORB API
@ 1998-11-17 03:55 Taral <taral@cyberjunkie.com>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 0 replies; 11+ messages in thread
From: Taral @ 1998-11-17 03:55 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; +Cc: Aleksey Demakov <avd@gcom.ru>; pgsql-interfaces
> 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
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [INTERFACES] ORB API
@ 1998-11-17 06:04 Aleksey Demakov <avd@gcom.ru>
parent: Taral <taral@cyberjunkie.com>
1 sibling, 0 replies; 11+ messages in thread
From: Aleksey Demakov @ 1998-11-17 06:04 UTC (permalink / raw)
To: pgsql-interfaces; orbit-list@cuc.edu
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
^ permalink raw reply [nested|flat] 11+ messages in thread
end of thread, other threads:[~1998-11-17 06:04 UTC | newest]
Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1998-11-15 07:24 ORB API Taral <taral@cyberjunkie.com>
1998-11-16 05:13 ` Aleksey Demakov <avd@gcom.ru>
1998-11-16 05:36 ` The Hermit Hacker <scrappy@hub.org>
1998-11-16 15:29 ` Taral <taral@cyberjunkie.com>
1998-11-17 03:14 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-11-17 03:55 ` Taral <taral@cyberjunkie.com>
1998-11-17 06:04 ` Aleksey Demakov <avd@gcom.ru>
1998-11-16 06:04 Re: [INTERFACES] ORB API Michael Robinson <robinson@public.bta.net.cn>
1998-11-16 13:23 ` The Hermit Hacker <scrappy@hub.org>
1998-11-16 15:32 ` Taral <taral@cyberjunkie.com>
1998-11-16 13:45 Re: [INTERFACES] ORB API Michael Robinson <robinson@public.bta.net.cn>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox