Обсуждение: CORBA interface in backend?
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? -Michael Robinson
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 Hamburgprivate: 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, 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!