Re: [HACKERS] CORBA STATUS - Mailing list pgsql-hackers

> > 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