CORBA interface in backend?

On Wed, 11 Nov 1998, Michael Robinson wrote:

I've been banging and banging my head against the specific problem of how
to tightly couple the object-relational part of postgres with the object-
list processing part of Python. In the midst of this head-banging, I thought
of this possible general solution:

Put an ORB in the backend.

Not only would this, in theory, give fairly reasonable performance for
persistent object store applications in Python, it would open up PostgreSQL
for interoperability with any CORBA-interfaced application. Now that
PostgreSQL has something of a stored procedural language, that makes it
even more attractive.

What I envision is a "dumpIDL" command that, for certain input parameters
(table/class) would dump the appropriate IDL definition for instances(rows)
of that class and related methods(functions). And then hack an existing
ORB onto the backend to do all the translation, communications and
bookkeeping.

So, I'm soliciting opinions: is this brain fart worth pursuing, or should
I just forget it ever happened?

How would this tie into the existing system? Does this become an
extension of it, or replace parts of it?

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

Put an ORB in the backend.

How would this tie into the existing system? Does this become an
extension of it, or replace parts of it?

Probably neither. It looks to me like it would be an alternate to the
current system. So the parser, etc. all stay in place, and the storage
system can be changed out for the ORB.

Or do I have the function of an ORB wrong? (It would help if I could
remember exactly what it stands for...)

Taral

On Wed, Nov 11, 1998 at 01:33:52PM +0800, Michael Robinson wrote:

Put an ORB in the backend.

Sounds good IMO. Although I have to admit I'm not really well informed about
Corba.

Not only would this, in theory, give fairly reasonable performance for
persistent object store applications in Python, it would open up PostgreSQL
for interoperability with any CORBA-interfaced application. Now that
PostgreSQL has something of a stored procedural language, that makes it
even more attractive.

Once again agreed.

What I envision is a "dumpIDL" command that, for certain input parameters
(table/class) would dump the appropriate IDL definition for instances(rows)
of that class and related methods(functions). And then hack an existing
ORB onto the backend to do all the translation, communications and
bookkeeping.

This is where it gets tricky. Which existing ORB are you thinking about? I
know of only two free ORBs: The Gnome one (orbit) and mico. Orbit is GPLed
so there's a problem with PostgreSQL becoming GPLed. However, as long as
PostgreSQL remain free under the BSD license that should be okay. But we
defintely lose the possibility to make this a commercial product. Not that
we want to do so.

Mico on the other hand is said to be pretty slow. I haven't tested it myself
though. And I have no idea what the license situation is.

So, I'm soliciting opinions: is this brain fart worth pursuing, or should
I just forget it ever happened?

I'd say keep on thinking.

Michael
--
Dr. Michael Meskes, Leiter Niederlassung West, Datenrevision GmbH
business: Cuxhavener Str. 36, D-21149 Hamburg
private: Th.-Heuss-Str. 61, D-41812 Erkelenz, Michael.Meskes@usa.net
Go SF49ers! Go Rhein Fire! Use Debian GNU/Linux!

On Wed, 11 Nov 1998, Michael Meskes wrote:

This is where it gets tricky. Which existing ORB are you thinking about? I
know of only two free ORBs: The Gnome one (orbit) and mico. Orbit is GPLed
so there's a problem with PostgreSQL becoming GPLed. However, as long as
PostgreSQL remain free under the BSD license that should be okay. But we
defintely lose the possibility to make this a commercial product. Not that
we want to do so.

Both are GPLd then, as I'm doing work with MICO and FreeBSD, and
just checked their license files.

Now, here is where *I* get confused. MICO uses LGPL for its
libraries, so does this mean that the ORB hooks could be added where
applicable, still under the BSD license, but in order to compile it in,
mico's libraries would have to be installed first? Its something we
check for/do with the tcl stuff...

So, could the ORB hooks be added with a config option of
'--enable-orb' *without* the requirement for adding in any GPLd code?

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

On Wed, 11 Nov 1998, Michael Meskes wrote:

This is where it gets tricky. Which existing ORB are you thinking about?

I

know of only two free ORBs: The Gnome one (orbit) and mico. Orbit is

GPLed

so there's a problem with PostgreSQL becoming GPLed. However, as long as
PostgreSQL remain free under the BSD license that should be okay. But we
defintely lose the possibility to make this a commercial product. Not

that

we want to do so.

there's also omniORB (http://www.orl.co.uk) which i found when i was looking
for vnc. haven't used it, don't know much about it, but i believe it's also
LGPL'd (maybe GPL'd)

Both are GPLd then, as I'm doing work with MICO and FreeBSD, and
just checked their license files.

Now, here is where *I* get confused. MICO uses LGPL for its
libraries, so does this mean that the ORB hooks could be added where
applicable, still under the BSD license, but in order to compile it in,
mico's libraries would have to be installed first? Its something we
check for/do with the tcl stuff...

So, could the ORB hooks be added with a config option of
'--enable-orb' *without* the requirement for adding in any GPLd code?

an abstract orb interface? sounds good as long as someone else is doing the
work.

know of only two free ORBs: The Gnome one (orbit) and mico.

there's also omniORB (http://www.orl.co.uk)

ILU is also available from Xerox/parc, and has a license very close to
the Berkeley license for Postgres. The only extra is a copyright term
saying that the s/w must be distributed in a way which conforms to U.S.
export laws. afaik that is just to protect Xerox' bank account from
trouble caused by others.

- Tom

On Thu, Nov 12, 1998 at 05:22:37AM +0000, Thomas G. Lockhart wrote:

ILU is also available from Xerox/parc, and has a license very close to
the Berkeley license for Postgres. The only extra is a copyright term
saying that the s/w must be distributed in a way which conforms to U.S.
export laws. afaik that is just to protect Xerox' bank account from
trouble caused by others.

Then we're out of trouble. :-) Let's just hope this ORB is good enough. :-)

Michael
--
Dr. Michael Meskes, Leiter Niederlassung West, Datenrevision GmbH
business: Cuxhavener Str. 36, D-21149 Hamburg
private: Th.-Heuss-Str. 61, D-41812 Erkelenz, Michael.Meskes@usa.net
Go SF49ers! Go Rhein Fire! Use Debian GNU/Linux!

On Wed, Nov 11, 1998 at 03:30:06PM -0400, The Hermit Hacker wrote:

Both are GPLd then, as I'm doing work with MICO and FreeBSD, and
just checked their license files.

Now, here is where *I* get confused. MICO uses LGPL for its
libraries, so does this mean that the ORB hooks could be added where
applicable, still under the BSD license, but in order to compile it in,
mico's libraries would have to be installed first? Its something we
check for/do with the tcl stuff...

Yes. As long as we add the ORB hooks ourselves (or use some under the BSD
copyright) this is fine. Just linking a program against an LGPLed library
does not force you to (L)GPL the program.

So, could the ORB hooks be added with a config option of
'--enable-orb' *without* the requirement for adding in any GPLd code?

Yes, I think so.

Michael
--
Dr. Michael Meskes, Manager of the Western Branch Office, Datenrevision GmbH
work: Cuxhavener Str. 36, D-21149 Hamburg
home: Th.-Heuss-Str. 61, D-41812 Erkelenz, Michael.Meskes@usa.net
Go SF49ers! Go Rhein Fire! Use Debian GNU/Linux!