Thread: CORBA STATUS

> Is there room for me to work on this project in such a way that it is
> adequate for my masters. If anyone is working on this, or has a good
> knowledge of the current status of the CORBA implementation for PGsql can
> you please let me know, so I can know whether to get started on this or not.
> The reference thread for my initial point of contact with Marc G. Fournier
> and Bruce Momjian and how they think I should attack the project is -
> http://www.postgresql.org/mhonarc/pgsql-hackers/1999-09/msg00076.html

I know of no one working on it.  There were two ideas as I remember. 
One was to replace our existing client/server communication with corba,
and the second was to have a corba server that accepted corba requests
and sent them to a PostgreSQL server.  I prefer this second approach as
I think CORBA may be too much overhead for people who don't need it. 
Our current client/server communication is quite efficient.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

> > Is there room for me to work on this project in such a way that it is
> > adequate for my masters. If anyone is working on this, or has a good
> > knowledge of the current status of the CORBA implementation for PGsql can
> > you please let me know, so I can know whether to get started on this or not.
> > The reference thread for my initial point of contact with Marc G. Fournier
> > and Bruce Momjian and how they think I should attack the project is -
> > http://www.postgresql.org/mhonarc/pgsql-hackers/1999-09/msg00076.html
> I know of no one working on it.

Right. No one is working on it, or if they are they haven't told
anyone. It's all yours ;)

> There were two ideas as I remember.
> One was to replace our existing client/server communication with corba,
> and the second was to have a corba server that accepted corba requests
> and sent them to a PostgreSQL server.  I prefer this second approach as
> I think CORBA may be too much overhead for people who don't need it.
> Our current client/server communication is quite efficient.

Actually, our current protocol is about the best you can do assuming
that you don't have something as powerful as Corba to do it right.

In the time since Corba was first brought up wrt Postgres, I have been
involved with extensive Corba development for a family of systems at
work. It is a tremendously powerful standard, though just
re-implementing the existing interfaces using Corba would probably
defeat the power and flexibility Corba can give you.

Postgres currently avoids endian and other data representation issues
between client and server by converting all data to strings. Corba can
efficiently pass binary info back and forth, automatically handling
endian issues *if necessary*. This alone should make a Corba-based
interface using native internal representations of data types more
efficient both in speed and size than our current scheme.

Using Corba's DII, we might even cope with Postgres' type
extensibility features in a transparent manner.

One trick will be to choose a Corba ORB to use on the server side. It
should probably be a C implementation, though Corba more naturally
maps to an OO language such as C++. It will be a trick to find an ORB
which is supported on as many platforms as Postgres is. One of the
most portable ORBs is TAO, which we are using at work, but that is C++
and involves 1.3GB of disk space to fully build!! But the runtime
sizes are pretty reasonable, adding just a few megabytes of shared
libraries to a plain-vanilla client/server application.

imho it will be extremely difficult to find an ORB which could be
injected directly into the Postgres server. It would likely reduce the
number of platforms Postgres runs on, and would not be considered
acceptable.

For a first cut, you might consider Bruce's "plan B", which involves
writing a new client to the Postgres backend, which would be a Corba
server to other clients. That would allow you to start working with
Corba without hacking up the backend early on.

At the extreme end, fully Corba-ized Postgres server is an intriguing
thought, allowing backend to be broken up into distributable modules.

Have fun thinking about the possibilities...
                   - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

Then <lockhart@alumni.caltech.edu> spoke up and said:
> imho it will be extremely difficult to find an ORB which could be
> injected directly into the Postgres server. It would likely reduce the
> number of platforms Postgres runs on, and would not be considered
> acceptable.

On the other hand, this is where the power of configure comes into
play.  Assuming we have servers for multiple ORBs, configure can look
to see what's installed (TAO, Orbit, whatever) and then build only
that server.

-- 
=====================================================================
| JAVA must have been developed in the wilds of West Virginia.      |
| After all, why else would it support only single inheritance??    |
=====================================================================
| Finger geek@cmu.edu for my public key.                            |
=====================================================================

On 9 Nov 1999, Brian E Gallew wrote:

> Then <lockhart@alumni.caltech.edu> spoke up and said:
> > imho it will be extremely difficult to find an ORB which could be
> > injected directly into the Postgres server. It would likely reduce the
> > number of platforms Postgres runs on, and would not be considered
> > acceptable.
> 
> On the other hand, this is where the power of configure comes into
> play.  Assuming we have servers for multiple ORBs, configure can look
> to see what's installed (TAO, Orbit, whatever) and then build only
> that server.

ACtually, I believe Thomas was referring to those platforms that we
currently support that have no ORBs available to them...being a "purely C"
server so far, how many of our currently supported platforms are we going
to cut off with this? 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

Then <scrappy@hub.org> spoke up and said:
> ACtually, I believe Thomas was referring to those platforms that we
> currently support that have no ORBs available to them...being a "purely C"
> server so far, how many of our currently supported platforms are we going
> to cut off with this? 

But that's just it: we're not cutting anybody off.  We may not have a
CORBA server available for that platform, but the standard server will
continue to work quite nicely.  I guess that I'm looking at this more
as contrib code than as mainstream, required functionality.  Besides,
once the CORBA server is built on a platform that can support it,
clients can run from (basically) anywhere.

-- 
=====================================================================
| JAVA must have been developed in the wilds of West Virginia.      |
| After all, why else would it support only single inheritance??    |
=====================================================================
| Finger geek@cmu.edu for my public key.                            |
=====================================================================

> > > imho it will be extremely difficult to find an ORB which could be
> > > injected directly into the Postgres server. It would likely reduce the
> > > number of platforms Postgres runs on, and would not be considered
> > > acceptable.
> > On the other hand, this is where the power of configure comes into
> > play.  Assuming we have servers for multiple ORBs, configure can look
> > to see what's installed (TAO, Orbit, whatever) and then build only
> > that server.

In the long run, that would be neat. In the short run, the details of
each ORB vary considerably wrt, for example, the names and numbers of
#include files. So it would complicate the code to try bringing along
two ORBs at the beginning. We might expect the ORBs to converge a bit
over time, so this will be easier later.

> ACtually, I believe Thomas was referring to those platforms that we
> currently support that have no ORBs available to them...being a "purely C"
> server so far, how many of our currently supported platforms are we going
> to cut off with this?

Don't know, and it doesn't matter (yet). We shouldn't avoid the issue
without someone looking at it further just because we *might* lose
some platforms; better to push it farther as a demonstration at least
before deciding that it isn't a possibility.

Anyway, I know that at least one ORB, TAO, runs on many more types of
platforms than Postgres does (e.g. VxWorks, Lynx, Solaris, NT, ...),
though Postgres runs on more Unix-style platforms. But that particular
ORB is not a good candidate for us, for reasons I already mentioned
(C++, large build size, poor configure support).
                   - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

I have done some research into slapping
a CORBA interface onto the PgSQL server.
I have looked at ORBit but my findings 
seems to apply to most CORBA implementations.

I found that there is a fundamental problem
concerning the difference in process models
in pgsql and the POA (Portable Object Adaptor)
in CORBA implementations.

AFAICS, POA assumes a threaded server while
PgSQL uses a traditional forking model.

I see 3 ways to resolve this:

1. Adapt the PgSQL server to use threads instead of forking.  I am not sure we want to do this since it is a major
undertakingand will not help the rock solid stability  we expect from a professional RDBMS.
 

2. Write a Forking Object Adaptor (FOA).  Would be a big job but it would benefit other similar  projects. A FOA would
haveto be rewritten for every  ORB. If you want to do this I suggest starting with  ORBit since it is all C and thereby
easierto slap  onto PgSQL.
 

3. Extend postmaster to proxy CORBA requests.  Postmaster could fork of postgres processes  on incoming connections.
Postmasterwill keep   listening and proxying request and responses   to/from the postgres process through some kind  of
IPC.This will make the postmaster multithreaded   and the postgres processes still singlethreaded.
 

It is doubtful if the gains:
- standard-based protocols
- less code to maintain (?)
justifies the amount of work required.

An easier way out is to, as suggested by others,
implement the CORBA-service outside the server
itself. It will in some cases give some latency
related performance degrading compared to a 
in-server implementation.

One effort to do something like that
(and more) is gnome-db. Check out
http://www.gnome.org/gnome-db/

regards,
-----------------
Göran Thyni
On quiet nights you can hear Windows NT reboot!

> ACtually, I believe Thomas was referring to those platforms that we
> currently support that have no ORBs available to them...being a "purely C"
> server so far, how many of our currently supported platforms are we going
> to cut off with this?

OmniORB http://www.uk.research.att.com/omniORB/omniORBForm.html runs on
most
Unix-like platforms. It is free and it is pretty fast. I used it a about
18 months ago and it was already pretty good then.

Adriaan

On 09-Nov-99 Thomas Lockhart wrote:
>> > > imho it will be extremely difficult to find an ORB which could be
>> > > injected directly into the Postgres server. It would likely reduce the
>> > > number of platforms Postgres runs on, and would not be considered
>> > > acceptable.
>> > On the other hand, this is where the power of configure comes into
>> > play.  Assuming we have servers for multiple ORBs, configure can look
>> > to see what's installed (TAO, Orbit, whatever) and then build only
>> > that server.
> 
> In the long run, that would be neat. In the short run, the details of
> each ORB vary considerably wrt, for example, the names and numbers of
>#include files. So it would complicate the code to try bringing along
> two ORBs at the beginning. We might expect the ORBs to converge a bit
> over time, so this will be easier later.
> 
>> ACtually, I believe Thomas was referring to those platforms that we
>> currently support that have no ORBs available to them...being a "purely C"
>> server so far, how many of our currently supported platforms are we going
>> to cut off with this?
> 
> Don't know, and it doesn't matter (yet). We shouldn't avoid the issue
> without someone looking at it further just because we *might* lose
> some platforms; better to push it farther as a demonstration at least
> before deciding that it isn't a possibility.
> 
> Anyway, I know that at least one ORB, TAO, runs on many more types of
> platforms than Postgres does (e.g. VxWorks, Lynx, Solaris, NT, ...),
> though Postgres runs on more Unix-style platforms. But that particular
> ORB is not a good candidate for us, for reasons I already mentioned
> (C++, large build size, poor configure support).

IMHO, There has no ideal ORB for all platforms.
we use ORBacus (http://www.ooc.com), 
because it's the only known for me ORB, working without threads 
so its really faster and more stable than another ones under FreeBSD,
but it's not free.

May be it is better make directory CORBA under interfaces subtree
and time-to-time put objects for differend ORB's inside, 
into separate directory.

Probably, It's better to make separate configure for 
some parts of postgres distributions to allow users to build/upgrade
parts of postgres i.e psql or perl interface 




---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

On Tue, 9 Nov 1999, Dmitry Samersoff wrote:
> > Anyway, I know that at least one ORB, TAO, runs on many more types of
> > platforms than Postgres does (e.g. VxWorks, Lynx, Solaris, NT, ...),
> > though Postgres runs on more Unix-style platforms. But that particular
> > ORB is not a good candidate for us, for reasons I already mentioned
> > (C++, large build size, poor configure support).
> 
> IMHO, There has no ideal ORB for all platforms.
> we use ORBacus (http://www.ooc.com), 
> because it's the only known for me ORB, working without threads 
> so its really faster and more stable than another ones under FreeBSD,
> but it's not free.
  FNORB - http://www.dstc.edu.au/Products/Fnorb/  Fnorb is a CORBA 2.0 ORB written in Python. Free for non-commercial
use.

Oleg.
----    Oleg Broytmann     http://members.xoom.com/phd2/     phd2@earthling.net          Programmers don't die, they
justGOSUB without RETURN.
 

Whomever does this implementation, or works on this, needs to bear in mind
that there are several different ORBs out there, and the code should be
written in such a way that *I* can use MICO, Oleg here can use Fnorb,
someone  else can use ORBit, etc...I personally don't want to have to go
ut and grab <INSERT ORB of the Day here> just so that I can use CORBA,
when I already have Mico installed for other software...


On Tue, 9 Nov 1999, Oleg Broytmann wrote:

> On Tue, 9 Nov 1999, Dmitry Samersoff wrote:
> > > Anyway, I know that at least one ORB, TAO, runs on many more types of
> > > platforms than Postgres does (e.g. VxWorks, Lynx, Solaris, NT, ...),
> > > though Postgres runs on more Unix-style platforms. But that particular
> > > ORB is not a good candidate for us, for reasons I already mentioned
> > > (C++, large build size, poor configure support).
> > 
> > IMHO, There has no ideal ORB for all platforms.
> > we use ORBacus (http://www.ooc.com), 
> > because it's the only known for me ORB, working without threads 
> > so its really faster and more stable than another ones under FreeBSD,
> > but it's not free.
> 
>    FNORB - http://www.dstc.edu.au/Products/Fnorb/
>    Fnorb is a CORBA 2.0 ORB written in Python. Free for non-commercial
> use.
> 
> Oleg.
> ---- 
>     Oleg Broytmann     http://members.xoom.com/phd2/     phd2@earthling.net
>            Programmers don't die, they just GOSUB without RETURN.
> 
> 
> ************
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

> Whomever does this implementation, or works on this, needs to bear in mind
> that there are several different ORBs out there, and the code should be
> written in such a way that *I* can use MICO, Oleg here can use Fnorb,
> someone  else can use ORBit, etc...I personally don't want to have to go
> ut and grab <INSERT ORB of the Day here> just so that I can use CORBA,
> when I already have Mico installed for other software...

Then forget it. Corba implementations don't work this way (yet).

Sorry you're not interested...
                   - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

On Wed, 10 Nov 1999, Thomas Lockhart wrote:

> > Whomever does this implementation, or works on this, needs to bear in mind
> > that there are several different ORBs out there, and the code should be
> > written in such a way that *I* can use MICO, Oleg here can use Fnorb,
> > someone  else can use ORBit, etc...I personally don't want to have to go
> > ut and grab <INSERT ORB of the Day here> just so that I can use CORBA,
> > when I already have Mico installed for other software...
> 
> Then forget it. Corba implementations don't work this way (yet).

Wait...when we talked about this months back, I swore that one of the
conclusions *was* that this was possible...it would involve us doing
wrapper functions in our code that were defined in an include file based
on which ORB implementation was used...?

Basically...

pg_<corba function> maps to <insert mico corba function here>         or <insert orbit corba function here>
or<insert other implementation function here>
 

Has this ability changed? *raised eyebrow*


Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

> Wait...when we talked about this months back, I swore that one of the
> conclusions *was* that this was possible...it would involve us doing
> wrapper functions in our code that were defined in an include file based
> on which ORB implementation was used...?
> Basically...
> pg_<corba function> maps to <insert mico corba function here>
>                          or <insert orbit corba function here>
>                          or <insert other implementation function here>
> Has this ability changed? *raised eyebrow*

No, this probably is not necessary since the C or C++ mappings for
function calls in Corba are very well defined. 

What is not fully specified in the Corba standard is, for example,
which header files (and by what names) will be generated by the IDL
stubber, so each Orb has, or might have, different conventions for
include files. This probably impacts server-side code a bit more than
clients.

There is some interest for some Orbs to try lining up the header file
names, but I don't know how feasible it is in the short term.

We could probably isolate this into Postgres-specific header files,
but there will probably be Orb-specific #ifdef blocks in those
headers.
                   - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

On Wed, 10 Nov 1999, Thomas Lockhart wrote:

> > Wait...when we talked about this months back, I swore that one of the
> > conclusions *was* that this was possible...it would involve us doing
> > wrapper functions in our code that were defined in an include file based
> > on which ORB implementation was used...?
> > Basically...
> > pg_<corba function> maps to <insert mico corba function here>
> >                          or <insert orbit corba function here>
> >                          or <insert other implementation function here>
> > Has this ability changed? *raised eyebrow*
> 
> No, this probably is not necessary since the C or C++ mappings for
> function calls in Corba are very well defined. 
> 
> What is not fully specified in the Corba standard is, for example,
> which header files (and by what names) will be generated by the IDL
> stubber, so each Orb has, or might have, different conventions for
> include files. This probably impacts server-side code a bit more than
> clients.
> 
> There is some interest for some Orbs to try lining up the header file
> names, but I don't know how feasible it is in the short term.
> 
> We could probably isolate this into Postgres-specific header files,
> but there will probably be Orb-specific #ifdef blocks in those
> headers.

Is there any reason configure couldn't handle this?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null # include <std/disclaimers.h>       Have you
seenhttp://www.pop4.net?       Online Campground Directory    http://www.camping-usa.com      Online Giftshop
Superstore   http://www.cloudninegifts.com
 
==========================================================================

On Wed, 10 Nov 1999, Thomas Lockhart wrote:

> > Wait...when we talked about this months back, I swore that one of the
> > conclusions *was* that this was possible...it would involve us doing
> > wrapper functions in our code that were defined in an include file based
> > on which ORB implementation was used...?
> > Basically...
> > pg_<corba function> maps to <insert mico corba function here>
> >                          or <insert orbit corba function here>
> >                          or <insert other implementation function here>
> > Has this ability changed? *raised eyebrow*
> 
> No, this probably is not necessary since the C or C++ mappings for
> function calls in Corba are very well defined. 
> 
> What is not fully specified in the Corba standard is, for example,
> which header files (and by what names) will be generated by the IDL
> stubber, so each Orb has, or might have, different conventions for
> include files. This probably impacts server-side code a bit more than
> clients.
> 
> There is some interest for some Orbs to try lining up the header file
> names, but I don't know how feasible it is in the short term.
> 
> We could probably isolate this into Postgres-specific header files,
> but there will probably be Orb-specific #ifdef blocks in those
> headers.

Right, which is something that I thought we had pseudo-agreed upon the
last time through, that we woudl most likely require this...hadn't
realized it was for 'Orb-header files', but, IMHO, that's no worse then
putting in HAVE_MICO vs HAVE_ORBIT blocks and having it a configure
option...

See...I am interested, just not interested in having us tied to one
"vendor"...:)

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

On Wed, 10 Nov 1999, Vince Vielhaber wrote:

> On Wed, 10 Nov 1999, Thomas Lockhart wrote:
> 
> > > Wait...when we talked about this months back, I swore that one of the
> > > conclusions *was* that this was possible...it would involve us doing
> > > wrapper functions in our code that were defined in an include file based
> > > on which ORB implementation was used...?
> > > Basically...
> > > pg_<corba function> maps to <insert mico corba function here>
> > >                          or <insert orbit corba function here>
> > >                          or <insert other implementation function here>
> > > Has this ability changed? *raised eyebrow*
> > 
> > No, this probably is not necessary since the C or C++ mappings for
> > function calls in Corba are very well defined. 
> > 
> > What is not fully specified in the Corba standard is, for example,
> > which header files (and by what names) will be generated by the IDL
> > stubber, so each Orb has, or might have, different conventions for
> > include files. This probably impacts server-side code a bit more than
> > clients.
> > 
> > There is some interest for some Orbs to try lining up the header file
> > names, but I don't know how feasible it is in the short term.
> > 
> > We could probably isolate this into Postgres-specific header files,
> > but there will probably be Orb-specific #ifdef blocks in those
> > headers.
> 
> Is there any reason configure couldn't handle this?

As simple as a '--with-corba=mico' configure option ... or, I would think?


Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

> See...I am interested, just not interested in having us tied to one
> "vendor"...:)

I know. That still doesn't keep me from being in a bad mood after
spending 3.5 hours at the dentist yesterday :((

On the Corba fork vs thread issue:

It is true that the server process would need to be handed off to the
client in a different manner from the postmaster; with Corba you don't
just fork onto a different port and be done with it.

However, the postmaster *could* start up a server process and return
an IOR to the client, which givs the client a direct handle to the
server. The client would then initiate contact directly with the
server, and the postmaster is no longer involved.

afaik you could still fork in the postmaster, though whether our
streamlined tricks would work with every Orb is not certain. But that
is an optimization for our specific forking implementation, not a
fundamental feature.

As I mentioned, the real performance benefits come from having an
optimized query connection which bypasses the *expensive* string
conversions we currently use to pass data around.
                    - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

The Hermit Hacker wrote: >> Is there any reason configure couldn't handle this? > >As simple as a '--with-corba=mico'
configureoption ... or, I would think?
 
>From the point of view of a package maintainer, I would much prefer a
solution that separated the choice of Orb from the main build.

If the choice goes into configure, I will have to pick a single Orb and
build the Debian package for that, or else make packages for every
Orb that Debian supports.  It would be better if I could build a generic
Orb-enabled PostgreSQL and produce a little pg-orb connection library
for each Debian-supported Orb.


--      Vote against SPAM: http://www.politik-digital.de/spam/                ========================================
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver              PGP key from public servers; key
ID32B8FAA1                ========================================    "But thanks be to God, which giveth us the
victory     through our Lord Jesus Christ."                                  I Corinthians 15:57 
 

On Wed, 10 Nov 1999, Oliver Elphick wrote:
> The Hermit Hacker wrote:
>   >> Is there any reason configure couldn't handle this?
>   >
>   >As simple as a '--with-corba=mico' configure option ... or, I would think?
>  
> From the point of view of a package maintainer, I would much prefer a
> solution that separated the choice of Orb from the main build.
> 
> If the choice goes into configure, I will have to pick a single Orb and
> build the Debian package for that, or else make packages for every
> Orb that Debian supports.  It would be better if I could build a generic
> Orb-enabled PostgreSQL and produce a little pg-orb connection library
> for each Debian-supported Orb.

The same issue is true for the RPM's -- which ORB?  If I'm on RedHat Linux, the
choice of ORB is going to depend upon the choice of desktops -- KDE or GNOME. 
ORBit is packaged standard for GNOME -- KDE 2 is going to use something else --
now, my understanding of CORBA is quite limited -- Thomas, you have far more
experience, as you are actively developing CORBA stuff.  If I choose to install
just KDE, KDE's ORB is going to be installed -- if I install GNOME, ORBit is
going to be installed. If I install both (the default), both ORB's will be
resident.

I can force the installation of a particular ORB through dependencies, but
that seems messy to me.

I CAN produce multiple sets of packages -- but that's going to cause all
manner of confusion for users.

Is it possible in the CORBA context to do what Oliver mentioned with a 'pg_orb'
abstraction layer to a generic CORBA-enabled postgreSQL??

It may seem like Oliver and I are getting the cart before the horse, but
the strategic decision of how to integrate CORBA into the system is going to
have wide-ranging repercussions for integrators.
--Lamar Owen
WGCR Internet Radio
1 Peter 4:11

> The same issue is true for the RPM's -- which ORB?  If I'm on RedHat Linux, the
> choice of ORB is going to depend upon the choice of desktops -- KDE or GNOME.
> ORBit is packaged standard for GNOME -- KDE 2 is going to use something else --
> now, my understanding of CORBA is quite limited -- Thomas, you have far more
> experience, as you are actively developing CORBA stuff.  If I choose to install
> just KDE, KDE's ORB is going to be installed -- if I install GNOME, ORBit is
> going to be installed. If I install both (the default), both ORB's will be
> resident.

Right.

> I can force the installation of a particular ORB through dependencies, but
> that seems messy to me.

Not so bad, but I understand your point.

> I CAN produce multiple sets of packages -- but that's going to cause all
> manner of confusion for users.

Right. Not worth the effort.

> Is it possible in the CORBA context to do what Oliver mentioned with a 'pg_orb'
> abstraction layer to a generic CORBA-enabled postgreSQL??

Maybe, as a second step. The first step (which we are a *long* ways
away from; getting a consensus on how to proceed will take a miracle)
will be to get an implementation using one Orb with the feature set we
want.

> It may seem like Oliver and I are getting the cart before the horse, but
> the strategic decision of how to integrate CORBA into the system is going to
> have wide-ranging repercussions for integrators.

This may not be what people want to hear, and may not be what turns
out, but imho and imle ("little experience" ;)...

Corba is really intended to allow clients and servers implemented with
different Orb products to interoperate transparently. It has very
carefully stayed away from over-specifying exactly *how* a particular
client or server would be implemented for a particular Orb.

The header file conventions, or lack thereof, is a good example of
this. I'm familiar with a couple of the C++ Orbs. Mico produces a
single header file per interface, while TAO produces two. Hmm, it just
dawned on me that I might be able to jigger the output file names from
TAO's IDL compiler to make the names line up with Mico. Will get back
to you on this detail :)

Anyway, if Corba is in our future, I would think that we would work
with a single Orb for the server-side implementation, at least at
first. Once we are up and running, then we talk about how to slip in
someone's favorite other Orb.

For clients, we will have to pick and choose depending on the language
and features required. For example, TAO has portability and some
realtime features and optimizations that make it the *only* choice for
our realtime systems at work. But Mico has a nice TCL binding, so we
are using that to implement some TCL GUIs for commanding and telemetry
interfaces.

Not a big deal, and we quickly got over the *flap arms all over* "Oh
no! This Orb doesn't support language X!!!!".

btw, the Orb which has more language bindings than any other is ILU.
ILU predates Corba by several years, but it has evolved to support the
Corba standard in many areas.

Corba was primarily intended to decouple clients from servers.
Inter-orb transportability at the source code level was a secondary
concern, though the Corba standard, or at least some of the
conventions used in the open-source implementations, may be converging
a bit to help with the source portability. And the biggest
source-level portability concern, the call-level interfaces, is not a
problem.

As we are introducing Corba to new users at work (we've got O(20)
programmers who will be using it on our testbeds and ground
implementations for optical interferometers), I emphasize the
following:

1) Corba makes distributed computing easy, in that clients (the
calling programs) call servers (the subroutines) as though they were
local to the client. But in fact they could reside anywhere.

2) Specifying interfaces through IDL is a *great* way to design
systems. If you have the interface, then you know what you need to
implement. From then on, clients and servers, or callers and call-ees,
can be implemented independently. If we end up with Corba in our
server, then we could/should start specifying our internal interfaces
with IDL also.

3) Since clients and servers are decoupled through well-defined
interfaces, and since these interfaces can be decoupled "on the wire",
you have great flexibility in how you mix and match Orb products to
implement clients and servers. But afaik all of the Orbs have a "short
circuit" which will allow you to build Corba-enabled routines written
with that Orb into the same image, without taking a hit at runtime to
marshall/unmarshall/network/etc.

One in an occasional series... ;)
                - Thomas

btw, I'm guessing that the way to get Corba going is to have a code
freeze/fork, and have a few people work on demonstrating Corba using
that frozen version. Then we re-merge later if the Corba demo was a
success *and* if Corba is what we want in the main-line product. That
could happen during our 7.x series of releases, and if the world wants
Corba, we could mainstream it for v8.0.

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

Hi,
A (possibly) simple solution to the problems people seem to be having 
with the variety of incompatibilities between the various ORBs out there 
might be to simply produce a version for whatever ORB you like -- but publish 
the IDL interfaces and let people know enough of the background information 
so that if they want to use a different ORB than the 'baseline' 
implementation, this is the interface that they have to code to.
That way, -you- (whoever you are) who implement the PostgreSQL/CORBA 
interface can only do it for your ORB of choice, and others can make the 
appropriate interfaces for their ORBs -- and make them available for the rest 
of us, hopefully....

                        Brendan
-- 
Brendan McKenna    
Technical Director            Phone: +353-(0)61-338177 x4143
W3 Services Ltd.              Fax: +353-(0)61-338065
Innovation Centre            Email: brendan@w3s.ie
National Technological Park
Limerick
Ireland

"Oliver Elphick" <olly@lfix.co.uk> writes:

> From the point of view of a package maintainer, I would much prefer
> a solution that separated the choice of Orb from the main build.
> 
> If the choice goes into configure, I will have to pick a single Orb
> and build the Debian package for that, or else make packages for
> every Orb that Debian supports.  It would be better if I could build
> a generic Orb-enabled PostgreSQL and produce a little pg-orb
> connection library for each Debian-supported Orb.

It probably makes sense to try to get things working with one ORB, and
then see if it's worth generalising.  I'd guess ORBit is a good one to
start with since it's C-based, and it's pretty small: if I have to
install an extra package on my machine just to run PostgreSQL, I'm not
going to mind ORBit, whereas TAO might annoy me (IIRC, TAO is quite
big; I may be thinking of another ORB, though).  ORBit does IIOP, I
believe, so that covers GNOME and KDE people.

> It probably makes sense to try to get things working with one ORB, and
> then see if it's worth generalising.  I'd guess ORBit is a good one to
> start with since it's C-based, and it's pretty small: if I have to
> install an extra package on my machine just to run PostgreSQL, I'm not
> going to mind ORBit, whereas TAO might annoy me (IIRC, TAO is quite
> big; I may be thinking of another ORB, though).  ORBit does IIOP, I
> believe, so that covers GNOME and KDE people.

Yeah, TAO might annoy you; it takes 1.3GB of disk space to build,
though much less once built ;)
                    - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

Hello,
I am attempting to recover a database previously secured with pg_dump,
however on attempting to restore using 

pgsql < db_security_file 

I get the following error(s)


ERROR:  tbl_breeders relation already exists

I have removed all data tables and user from the database,
what am I over looking?

Stephen 

"Stephen Martin" <stephen@sealteam.demon.co.uk> el día Thu, 11 Nov 1999 
13:00:57 -0800, escribió:

>Hello,
>I am attempting to recover a database previously secured with pg_dump,
>however on attempting to restore using 
>
>pgsql < db_security_file 

bad, bad ...

go to /usr/doc/postgres and read ...


Sergio