Thread: More PostgreSQL+CORBA
CORBA in fifty words or less: CORBA is an architecture which specifies how to: - define the method signatures of
anobject type - obtain a reference to a object instance - invoke a method, with parameters, on an object instance
- receive the results - all interoperably between different programming languages, object implementations,
andplatforms.
Why CORBA? If you don't do object-oriented programming and system design, the rationale for CORBA will be hard to
understand. If you don't understand why PostgreSQL is called an "object-relational" database (and why every row has
anOID), the rationale for PostgreSQL+CORBA will be hard to understand. The short version goes like this:
Thinkof a database table as a "typedef" of a data structure, with each row representing a malloc'ed instance of that
structuretype. The database provides for persistant storage, and concurrent data access, but with a considerable
accessoverhead: sending an SQL query string down a socket, parsing the query string into an execution plan, executing
the plan, coverting the returned result set into text strings, sending the strings down a socket, retrieving the
stringsfrom the socket, and, finally, converting the text strings back into usable data values. With CORBA,
though,you could keep a reference (OID, pointer, etc.) to each data structure of interest, and just call a function
toread or write data to fields in that structure. Another way to think of it is cursors without queries. The
database(PostgreSQL in our case) continues to maintain persistence and concurrent access, and the data is also
alwaysavailable for relational queries.
Which ORB? GNOME started with Mico. Mico, apparently, makes use of C++ templates, which caused the compiler they
wereusing to generate bloated, wallowing code. GNOME then adopted ORBit, which has two wins: it's in C, and
(thisis the biggy) it has provisions to shortcut parameter marshalling, transmission, authentication, reception,
anddemarshalling--if the client stub and server skeleton are in the same address space, and both stub and skeleton
permitthis.
This means that, with ORBit, CORBA method calls can be almost as efficient as normal function calls.
How to use CORBA with PostgreSQL?
There are three ways I can see this working:
1. As a simple alternative for the current FE<->BE communication protocol. The SQL query engine continues to
intermediateall transactions. This has some benefits, but is really boring to me.
2. As an alternative to both the FE<->BE communication protocol and the SQL query engine. In this case,
programscould have efficient direct row access, but all data transfers would still be shoved through a socket
(viathe Internet Inter-Orb Protocol). This could be useful, and mildly interesting.
3. As an alternative API to libpq that would allow, for example, embedding a Python interpreter in the backend,
withPostgreSQL tables exposed through CORBA as native Python classes, and with high performance via ORBit
methodshortcutting. This, in my opinion, would be the most useful and interesting.
-Michael Robinson
On Sat, 14 Nov 1998, Michael Robinson wrote:
< a very well written description removed >
> Which ORB?
>
> GNOME started with Mico. Mico, apparently, makes use of C++ templates,
> which caused the compiler they were using to generate bloated, wallowing
> code.
Is that still accurate today?
> GNOME then adopted ORBit, which has two wins: it's in C, and (this is
> the biggy) it has provisions to shortcut parameter marshalling,
So...implement an OO 'environment' with a non-OO language? :)
My experience is that for pretty much every pro, there is a
con...what are we losing with ORBit that we'd have with mico? Short
and/or long term? mico is reputed to be Corba 2.2 compliant..orbit?
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Michael Robinson <robinson@public.bta.net.cn> writes:
> [ pithy summary of CORBA snipped --- thanks, Michael! ]
> There are three ways I can see this working:
> 1. As a simple alternative for the current FE<->BE communication protocol.
> The SQL query engine continues to intermediate all transactions. This
> has some benefits, but is really boring to me.
I agree, that's not too exciting ... although replacing our current ad-hoc
FE/BE protocol with a standards-based protocol (I assume CORBA has a
recognized standard for the wire-level protocol?) might well be worth doing.
> 2. As an alternative to both the FE<->BE communication protocol and the
> SQL query engine. In this case, programs could have efficient direct
> row access, but all data transfers would still be shoved through a
> socket (via the Internet Inter-Orb Protocol). This could be useful,
> and mildly interesting.
Actually, I find that one Extremely Useful and indeed Fascinating ;-).
In the applications I'm currently using, a large fraction of the
update queries act on single rows and have the formUPDATE table SET field(s) WHERE oid = 123456;
The overhead of doing this is horrendous, of course. Being able to
access individual rows as if they were CORBA objects would be a lovely
performance improvement, I suspect.
> 3. As an alternative API to libpq that would allow, for example,
> embedding a Python interpreter in the backend, with PostgreSQL tables
> exposed through CORBA as native Python classes, and with high
> performance via ORBit method shortcutting. This, in my opinion,
> would be the most useful and interesting.
I'm leery of this, not only because of the implementation problems other
people have mentioned (bringing the backend to a state where it is
thread-safe would be a large effort), but because it subverts all the
protection and security reasons for having the Postgres frontend/backend
architecture in the first place. The *last* thing I'd want is client
code executing in the same process as the database server.
However, if I understand things correctly, the CORBA interface will hide
whether client code is in the same process as the backend server or not;
so we could each assemble the parts in the way we prefer. At least, I
could build my separate-processes setup right away, and we could work
towards making the backend thread-safe so you could build your
installation your way.
Does CORBA have any provision for saying "this object is not thread
safe, don't send it concurrent operations"? If there's something along
that line, then maybe we don't have to fix the backend before it can
live in a common address space with the client...
regards, tom lane
> > 1. simple alternative for the current FE<->BE communication
> > protocol.
> ... although replacing our current ad-hoc
> FE/BE protocol with a standards-based protocol (I assume CORBA has a
> recognized standard for the wire-level protocol?) might well be worth
> doing.
Corba does specify a wire-level protocol, and also several layers above
that, so we would get endian issues resolved as well as
security/encryption, authentication, etc. Also, it may (at least
partially) address the need for different client libraries for different
languages, since there are Corba bindings available for a bunch of
languages. Some of that is up to the package one chooses to use...
- Tom
> Michael Robinson <robinson@public.bta.net.cn> writes: > > [ pithy summary of CORBA snipped --- thanks, Michael! ] > > > There are three ways I can see this working: > > > 1. As a simple alternative for the current FE<->BE communication protocol. > > The SQL query engine continues to intermediate all transactions. This > > has some benefits, but is really boring to me. > > I agree, that's not too exciting ... although replacing our current ad-hoc > FE/BE protocol with a standards-based protocol (I assume CORBA has a > recognized standard for the wire-level protocol?) might well be worth doing. Current FE/BE protocol seems pretty optimized to me, but you should know the best. Seems like a waste to try and get it to match some standard, expecially if we can just create a module to do it on top of the existing protocol. -- 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
On Fri, 13 Nov 1998, Bruce Momjian wrote:
> > Michael Robinson <robinson@public.bta.net.cn> writes:
> > > [ pithy summary of CORBA snipped --- thanks, Michael! ]
> >
> > > There are three ways I can see this working:
> >
> > > 1. As a simple alternative for the current FE<->BE communication protocol.
> > > The SQL query engine continues to intermediate all transactions. This
> > > has some benefits, but is really boring to me.
> >
> > I agree, that's not too exciting ... although replacing our current ad-hoc
> > FE/BE protocol with a standards-based protocol (I assume CORBA has a
> > recognized standard for the wire-level protocol?) might well be worth doing.
>
> Current FE/BE protocol seems pretty optimized to me, but you should know
> the best. Seems like a waste to try and get it to match some standard,
> expecially if we can just create a module to do it on top of the
> existing protocol.
Except...if I'm understanding even half of this correctly...by
implementing CORBA at the FE/BE level, this effectively eliminates the
need for *us* to maintain a seperate interface for each language we want
to support, since that is what one of CORBA's design goals is...
In fact, again, if I'm understanding this correctly, this could
potentially open us up to languages we currently don't support...?
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> Except...if I'm understanding even half of this correctly...by > implementing CORBA at the FE/BE level, this effectively eliminates the > need for *us* to maintain a seperate interface for each language we want > to support, since that is what one of CORBA's design goals is... > > In fact, again, if I'm understanding this correctly, this could > potentially open us up to languages we currently don't support...? Yea, that would be neat. But considering no one really totally supports CORBA yet, and we already have tons of working interfaces, perhaps we can consider it in the future, or were you thinking in the next 6-9 months? -- 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
On Sat, 14 Nov 1998, Bruce Momjian wrote:
> > Except...if I'm understanding even half of this correctly...by
> > implementing CORBA at the FE/BE level, this effectively eliminates the
> > need for *us* to maintain a seperate interface for each language we want
> > to support, since that is what one of CORBA's design goals is...
> >
> > In fact, again, if I'm understanding this correctly, this could
> > potentially open us up to languages we currently don't support...?
>
> Yea, that would be neat. But considering no one really totally supports
> CORBA yet, and we already have tons of working interfaces, perhaps we
> can consider it in the future, or were you thinking in the next 6-9
> months?
Guess that's the next question (vs statement)...who actually
supports Corba at this time? two, off the top of my head, are Gnome and
Koffice...anyone know of a list of others?
As for 6-9 months...I think this is more in Michael court then
anything...I don't see why work can't start on it now, even if its nothing
more then Michael submitting patches that have the relevant sections
#ifdef's so that they are only enabled for those working on it. I don't
imagine this is going to be a "now it isn't, now it is" sort of thing...it
might take 6-9 months to implement...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > Except...if I'm understanding even half of this correctly...by > > implementing CORBA at the FE/BE level, this effectively eliminates the > > need for *us* to maintain a seperate interface for each language we want > > to support, since that is what one of CORBA's design goals is... > > > > In fact, again, if I'm understanding this correctly, this could > > potentially open us up to languages we currently don't support...? > > Yea, that would be neat. But considering no one really totally supports > CORBA yet, and we already have tons of working interfaces, perhaps we > can consider it in the future, or were you thinking in the next 6-9 > months? I think I get it now. Currently, all the non-C interfaces use libpq to go over the wire to the backend. If we made the FE/BE protocol CORBA, we could modify libpq, and all the current interfaces would still work. Then if someone came up with a Smalltalk-to-CORBA interface, they could use it for PostgreSQL. Also, if someone came up with a better Perl-to-CORBA interface, we could throw ours away, and just use that one. Would nice. Hope there is no performance penalty. -- 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
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Yea, that would be neat. But considering no one really totally supports
> CORBA yet, and we already have tons of working interfaces, perhaps we
> can consider it in the future, or were you thinking in the next 6-9
> months?
I'm not sure what Michael was thinking, but I was seeing this as a
long-term kind of project. Maybe for the release after 6.5, or even
the one after that. (Do we have any definite plans for future release
frequency?)
Even if the open-source ORBs are adequately up-to-speed today (which
sounded iffy), we need to learn about CORBA, or import some expertise
from somewhere, before we can do much. This is unknown territory for
me, and evidently also for most of the pgsql crew. I'd be inclined to
just play around for a few months and try to write a paper design.
It does sound like an idea worth pursuing, though.
regards, tom lane
On Fri, Nov 13, 1998 at 01:39:17PM -0400, The Hermit Hacker wrote: > > GNOME started with Mico. Mico, apparently, makes use of C++ templates, > > which caused the compiler they were using to generate bloated, wallowing > > code. > > Is that still accurate today? I think so, yes. > > GNOME then adopted ORBit, which has two wins: it's in C, and (this is > > the biggy) it has provisions to shortcut parameter marshalling, > > So...implement an OO 'environment' with a non-OO language? :) > > My experience is that for pretty much every pro, there is a > con...what are we losing with ORBit that we'd have with mico? Short > and/or long term? mico is reputed to be Corba 2.2 compliant..orbit? In the short term we lose lots of functions with ORBit. In the long run however we win performance. 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!
Bruce Momjian wrote: > > Current FE/BE protocol seems pretty optimized to me, but you should know > the best. Seems like a waste to try and get it to match some standard, > expecially if we can just create a module to do it on top of the > existing protocol. > It may be pretty optimized, but in its current implementation it seems it has just evolved into the current shape, and not engineered to be a efficient and consistent interface. The way it has become as it is seems to be grown from the need to talk to the backend directly using telnet. Otherways the protocol is a bitch to implement (comared for example to X) as it is very inconsistent in ways lengths are specified, and also lacks many features needed from standard SQL CLI spec, like prepared statements and such; (Implementing prepared statements on top of current protocol would need quite a lot of gum, wire and black tape) The binary protocol is very much lacking (read unimplemented) - there are places for network input/output functions in the pg_type table, (I guess typsend/typreceive were ment to be used in binary mode cursors) but they are not used (they are always the same as typoutput/typsend) having really standard network independent binary representations (using typsend/typreceive) for all types would be one thing to ease implementation of higher-level client libraries (ODBC,JDBC,...) Currently everything goes through ascii as it is the only architecture and network independent way. I have been entertaining an idea to design a new protocol based on X Window protocol, but probably the CORBA one (GIOP ?) is more advanced, at least in fields like security, marshalling of new user-defined datatypes and others. It does probably not suffer from arbitrary 8k limits in unexpected places ;) So, as we will need a new FE<->BE protocol anyway, why not try to use CORBA. ------------- Hannu Krosing
Bruce Momjian wrote: > > > Yea, that would be neat. But considering no one really totally supports > > CORBA yet, and we already have tons of working interfaces, perhaps we > > can consider it in the future, or were you thinking in the next 6-9 > > months? > > I think I get it now. Currently, all the non-C interfaces use libpq to > go over the wire to the backend. AFAIK, many of them (ODBC,tcl(the portable one),JDBC) speak native wire-protocol. > If we made the FE/BE protocol CORBA, we > could modify libpq, and all the current interfaces would still work. > Then if someone came up with a Smalltalk-to-CORBA interface, they could > use it for PostgreSQL. Also, if someone came up with a better > Perl-to-CORBA interface, we could throw ours away, and just use that > one. > > Would nice. Hope there is no performance penalty. I don't know about it, it probably depends on which ORB we will use. ------------------ Hannu
Tom Lane wrote: > > Bruce Momjian <maillist@candle.pha.pa.us> writes: > > Yea, that would be neat. But considering no one really totally supports > > CORBA yet, and we already have tons of working interfaces, perhaps we > > can consider it in the future, or were you thinking in the next 6-9 > > months? > > I'm not sure what Michael was thinking, but I was seeing this as a > long-term kind of project. Maybe for the release after 6.5, or even > the one after that. (Do we have any definite plans for future release > frequency?) > > Even if the open-source ORBs are adequately up-to-speed today (which > sounded iffy), we need to learn about CORBA, or import some expertise > from somewhere, before we can do much. This is unknown territory for > me, and evidently also for most of the pgsql crew. I'd be inclined to > just play around for a few months and try to write a paper design. Keep an eye on the SQL CLI specs (or ODBC/JDBC as they are quite similar) when doing the design. > It does sound like an idea worth pursuing, though. Indeed. --------------- Hannu
On Sat, Nov 14, 1998 at 10:19:17AM -0400, The Hermit Hacker wrote: > supports Corba at this time? two, off the top of my head, are Gnome and > Koffice...anyone know of a list of others? Koffice? Is there anything like this yet? I know they are planning for it. Or did you mean KDE? Do they use an ORB? Which one? 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!
On Sat, Nov 14, 1998 at 02:34:04AM -0500, Bruce Momjian wrote: > Yea, that would be neat. But considering no one really totally supports > CORBA yet, and we already have tons of working interfaces, perhaps we > can consider it in the future, or were you thinking in the next 6-9 > months? I'd say start woking now. But when it will be ready is up in the air. And hey why shouldn't we be the first? 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!
> Bruce Momjian wrote: > > > > > Yea, that would be neat. But considering no one really totally supports > > > CORBA yet, and we already have tons of working interfaces, perhaps we > > > can consider it in the future, or were you thinking in the next 6-9 > > > months? > > > > I think I get it now. Currently, all the non-C interfaces use libpq to > > go over the wire to the backend. > > AFAIK, many of them (ODBC,tcl(the portable one),JDBC) speak native > wire-protocol. Oops, I forgot about those. -- 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
On Sat, 14 Nov 1998, Michael Meskes wrote: > I'd say start woking now. But when it will be ready is up in the air. And > hey why shouldn't we be the first? > > Michael I *like* that attitude! I'm researching CORBA now, to see if ORBit is sufficient for our needs. Taral
On Sat, 14 Nov 1998, Michael Meskes wrote:
> On Fri, Nov 13, 1998 at 01:39:17PM -0400, The Hermit Hacker wrote:
> > > GNOME started with Mico. Mico, apparently, makes use of C++ templates,
> > > which caused the compiler they were using to generate bloated, wallowing
> > > code.
> >
> > Is that still accurate today?
>
> I think so, yes.
>
> > > GNOME then adopted ORBit, which has two wins: it's in C, and (this is
> > > the biggy) it has provisions to shortcut parameter marshalling,
> >
> > So...implement an OO 'environment' with a non-OO language? :)
> >
> > My experience is that for pretty much every pro, there is a
> > con...what are we losing with ORBit that we'd have with mico? Short
> > and/or long term? mico is reputed to be Corba 2.2 compliant..orbit?
>
> In the short term we lose lots of functions with ORBit. In the long run
> however we win performance.
I was talking with a friend of mine down here, that I was *hoping*
would have posted by now since I really really hate translating what
someone else said, but...
We should be able to create a 'mapping' include file, like we've
done in other places, that maps one 'corba' implementations functions to
our own, so that which implementation (OMNIorb, ORBit, MICO, etc) someone
uses is up to them.
For instance, I already have MICO installed because of
koffice...I'd prefer not to have to install *another* one because I want
to use it for PostgreSQL.
My thought, at this point in time, is that this should be
implemented initially in mico, since ORBit is missing 857+ 'methods'(?)
... but program it generic enough that by a simple #ifdef in a single
include file, it can be extended to any of the other ones as desired...
...basically, don't lock us down to one implementation...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Sat, 14 Nov 1998, Bruce Momjian wrote:
> > > Except...if I'm understanding even half of this correctly...by
> > > implementing CORBA at the FE/BE level, this effectively eliminates the
> > > need for *us* to maintain a seperate interface for each language we want
> > > to support, since that is what one of CORBA's design goals is...
> > >
> > > In fact, again, if I'm understanding this correctly, this could
> > > potentially open us up to languages we currently don't support...?
> >
> > Yea, that would be neat. But considering no one really totally supports
> > CORBA yet, and we already have tons of working interfaces, perhaps we
> > can consider it in the future, or were you thinking in the next 6-9
> > months?
>
> I think I get it now. Currently, all the non-C interfaces use libpq to
> go over the wire to the backend. If we made the FE/BE protocol CORBA, we
> could modify libpq, and all the current interfaces would still work.
> Then if someone came up with a Smalltalk-to-CORBA interface, they could
> use it for PostgreSQL. Also, if someone came up with a better
> Perl-to-CORBA interface, we could throw ours away, and just use that
> one.
Ya, was talking to Duane today (he's out there somewhere...just
shy or something *grin*) ... he said there is, get this, a COBOL-to-Corba
interface... :)
It basically opens us up to more languages supported without
having to actually support them :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Sat, 14 Nov 1998, Michael Meskes wrote:
> On Sat, Nov 14, 1998 at 02:34:04AM -0500, Bruce Momjian wrote:
> > Yea, that would be neat. But considering no one really totally supports
> > CORBA yet, and we already have tons of working interfaces, perhaps we
> > can consider it in the future, or were you thinking in the next 6-9
> > months?
>
> I'd say start woking now. But when it will be ready is up in the air. And
> hey why shouldn't we be the first?
We weren't sure over here, but does Oracle support ORBs?
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Sat, 14 Nov 1998, Michael Meskes wrote:
> On Sat, Nov 14, 1998 at 10:19:17AM -0400, The Hermit Hacker wrote:
> > supports Corba at this time? two, off the top of my head, are Gnome and
> > Koffice...anyone know of a list of others?
>
> Koffice? Is there anything like this yet? I know they are planning for it.
> Or did you mean KDE? Do they use an ORB? Which one?
Koffice is in alpha stages right now, screen shots look good...I
just finally got a clean compile of mico under FreeBSD, so next is to get
koffice done up too...
And, yes, they use an orb...mico, in particular :)
Check out koffice.kde.org...looks promising...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Sat, 14 Nov 1998, Taral wrote:
> On Sat, 14 Nov 1998, Michael Meskes wrote:
>
> > I'd say start woking now. But when it will be ready is up in the air. And
> > hey why shouldn't we be the first?
> >
> > Michael
>
> I *like* that attitude! I'm researching CORBA now, to see if ORBit is
> sufficient for our needs.
Taral...
I'm putting *one* condition on all this...any code added to C
files *must* be of the sort that is generic enough that someone can decide
upon installation which implementation they want to use. For this, you
will need to do a corba.h file that contains:
#ifdef USING_MICO
#define ... ...
#elif USING_ORBIT
#define ... ...
#endif
I don't care if what you guys are working on only has ORBit stuff
in the corba.h file, but I (or anyone else) has to be able to modify that
one file in order for it to work with MICO also...or OMNIorb, or some
commercial product...
And, as I said before, there is no reason why any one of you has
to get a "working model" on your machine before starting to submit
patches. That kills productivity from the standpoint that two ppl are
going to end up working on the same functionality, independent of each
other...
Feel free to submit code such that:
#ifdef ENABLE_CORBA<corba related stuff>
#else /* original method */<old style stuff>
#endif
Too easy to add a --enable-corba option to configure...but at
least this way everyone sees what and where everyone else is working. In
the end, when it comes time to do it, we can strip that all out, but this
is looking like a fairly long term project, and with the ongoing changes
that go on in the code, getting the CORBA code in while all the other
changes are going on is a good thing in that it keeps code trees in
sync...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Sat, 14 Nov 1998, The Hermit Hacker wrote: > We weren't sure over here, but does Oracle support ORBs? They have their own (very good) ORB included with their Application Server platform. -- Todd Graham Lewis 32�49'N,83�36'W (800) 719-4664, x2804 ******Linux****** MindSpring Enterprises tlewis@mindspring.net
On Sat, 14 Nov 1998, The Hermit Hacker wrote: > For instance, I already have MICO installed because of > koffice...I'd prefer not to have to install *another* one because I want > to use it for PostgreSQL. If I may, I'd like to put in a plug for ORBit. DISCLAIMER: I am the GNOME FAQ maintainer. The GNOME project abandoned MICO and began the ORBit project for two main reasons: MICO is a memory hog, and MICO is pretty deeply C++-only. We took a serious look at fixing these problems with MICO, but could not see a way to solve them. (I think that some of it had to do with MICO's dependence on C++ templates, but I am not sure. I only know of this evaluation second-hand.) The ORBit developers intend on ORBit being fast, compliant, and multi-lingual. They are right now working on C++ support so that our KDE brothers can make use of ORBit and help us develop it. Again, I am a GNOME partisan, but I really do think that ORBit is a good choice and a reliable long-term investment. I encourage the PostgreSQL developers to consider it. BTW, I've recently joined the hackers list. I've used PostgreSQL for over a year and just began another project using it. I'll mostly be lurking, but if I can be of help to any of you, then please feel free to call on me. -- Todd Graham Lewis 32�49'N,83�36'W (800) 719-4664, x2804 ******Linux****** MindSpring Enterprises tlewis@mindspring.net
On Sat, 14 Nov 1998, Todd Graham Lewis wrote:
> On Sat, 14 Nov 1998, The Hermit Hacker wrote:
>
> > For instance, I already have MICO installed because of
> > koffice...I'd prefer not to have to install *another* one because I want
> > to use it for PostgreSQL.
>
> If I may, I'd like to put in a plug for ORBit. DISCLAIMER: I am the
> GNOME FAQ maintainer.
this isn't actually a voting process here...I don't want us locked
into one implementation. there are ppl out there that would prefer to use
mico because it is already installed on their system for some reason or
another...there should be absolutely no reason why this can't be coded
generic enough that, through a simple switch when running configure, one
or the other can be used...no?
> Again, I am a GNOME partisan, but I really do think that ORBit is a
> good choice and a reliable long-term investment. I encourage the
> PostgreSQL developers to consider it.
I would rather our implementatin be "non-partisan"...what happens
in a years time, or 6 months, when the "faults" in mico disappear, if they
do? at least if we work at staying non-partisan as far as which
implementation is used, switching will be transparent...all of them will
already be supported.
Bear in mind that ORBit and MICO are free implementations...what
about the commercial ones out there? Just like we tend to try and support
each OSs C compiler, I want us to stay non-partisan as far as any
"external tools" are concerned...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > > > > > My experience is that for pretty much every pro, there is a > > > con...what are we losing with ORBit that we'd have with mico? Short > > > and/or long term? mico is reputed to be Corba 2.2 compliant..orbit? > > > > In the short term we lose lots of functions with ORBit. In the long run > > however we win performance. > > I was talking with a friend of mine down here, that I was *hoping* > would have posted by now since I really really hate translating what > someone else said, but... ok, ok, Marc... you've got me into it now... :) I started thinking about that talking to Marc about the CORBA ORB issue. GNOME wants ORBit, BSD'ers want mico, linux'ers want omniorb, etc... (forgive any possible generalizations above) Basically what I was saying to Marc is that the really ORB-dependent part of CORBA is the IDL-to-<language> mappings. The logic of the CORBA object can be implemented as a normal object independent of the compiled stub. Then, all that has to be done is to fill in the stubs with code that acts as an adaptor to the ORB-independent object. That way porting to another ORB should be trivial. Someone out there correct me if I'm wrong... :) I do like the idea of using CORBA to access postgreSQL. There is the obvious advantage of not having to worry about porting libpg to every system and language. CORBA ORB vendors/developers can take care of that. What really makes me curious is what the object's interface will be... Just a clone of libpg, or something more?... I think someone earlier mentioned possibly doing things like directly referencing "objects." I think that the use of CORBA could allow for much more functionality than a classical SQL RDBMS interface. I don't know that much about the backend, but it could be interesting to throw some ideas back and forth about what could be done with the interface. I would personally prefer to have a more natural OO interface to the database, possibly expanding on the idea of being able to directly reference objects (and hold the reference to them). Duane -------------------------------------------- Duane Currie (dcurrie@sandman.acadiau.ca) Unix System Administrator/Software Developer Acadia Institute for Teaching and Technology --------------------------------------------
Hear ye! Hear ye! I've just started stressing my brain on the CORBA 2 docs... It turns out that CORBA will be completely compatible with the existing system. postmaster will register a "method server" with the ORB (which is a separate process in mico, at least). A "method server" is one which requires a separate process for every method invocation. Which is basically what we do now with our one-backend-per-connection system. At least until the backend is thread-safe, we're stuck with it. When the backend is thread-safe, we can switch to "unshared server" where we have one per database. :) Taral P.S. When will that corba-specific list be set up? I'm sure that well over half of the list didn't care one bit about what I just said.
On Sat, Nov 14, 1998 at 10:38:34PM -0400, The Hermit Hacker wrote:
> On Sat, 14 Nov 1998, Todd Graham Lewis wrote:
>
> > On Sat, 14 Nov 1998, The Hermit Hacker wrote:
> >
> > > For instance, I already have MICO installed because of
> > > koffice...I'd prefer not to have to install *another* one because I want
> > > to use it for PostgreSQL.
> >
> > If I may, I'd like to put in a plug for ORBit. DISCLAIMER: I am the
> > GNOME FAQ maintainer.
>
> this isn't actually a voting process here...I don't want us locked
> into one implementation. there are ppl out there that would prefer to use
> mico because it is already installed on their system for some reason or
> another...there should be absolutely no reason why this can't be coded
> generic enough that, through a simple switch when running configure, one
> or the other can be used...no?
You may not want that, but you had better look again. CORBA defines the
wire transactions very carefully. It defines the API for invoking
services very carefully. It very carefully avoids defining client
initialization, memory layout, API, etc. There is limited code
portability. Yes, conditional compilation will work, but it will be
a lot of effort, probably as much as maintaining a NT/Unix port.
Choose the first ORB carefully! Internal APIs for service
implementation is simillarly undefined.
>
> > Again, I am a GNOME partisan, but I really do think that ORBit is a
> > good choice and a reliable long-term investment. I encourage the
> > PostgreSQL developers to consider it.
>
> I would rather our implementatin be "non-partisan"...what happens
> in a years time, or 6 months, when the "faults" in mico disappear, if they
> do? at least if we work at staying non-partisan as far as which
> implementation is used, switching will be transparent...all of them will
> already be supported.
>
Personally I have trouble with both ORBit and MICO. MICO is far too
memory intensive and SLOW. Choosing MICO will be an enormous
performance hit.
I worry about ORBit because I think that GNOME has seriously
underestimated the amount of work involved in implementing anORB, not to mention the services.
If you are going to do this, look carefully before you leap.
At least look at ORBit, OmniORB2, ACE+TAO, ilu. Drop MICO
as the performance will simply be too bad.
> Bear in mind that ORBit and MICO are free implementations...what
> about the commercial ones out there? Just like we tend to try and support
> each OSs C compiler, I want us to stay non-partisan as far as any
> "external tools" are concerned...
>
Great ideal, but as CORBA lacks this level of source compatibility,
you can't get there.
> Marc G. Fournier
> Systems Administrator @ hub.org
> primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
>
>
On Sat, Nov 14, 1998 at 09:57:18PM -0400, The Hermit Hacker wrote: > Koffice is in alpha stages right now, screen shots look good...I > just finally got a clean compile of mico under FreeBSD, so next is to get > koffice done up too... So what software do they use? In particular of course I'd like to know whether they use PostgreSQL as DB backend. > And, yes, they use an orb...mico, in particular :) But mico isn't used for the complete KDE system (/or is it?), whereas Gnome uses its ORB almost everywhere it seems. 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!
On Sat, Nov 14, 1998 at 09:49:48PM -0400, The Hermit Hacker wrote: > For instance, I already have MICO installed because of > koffice...I'd prefer not to have to install *another* one because I want > to use it for PostgreSQL. Hey Marc, this shouldn't be the reason to decide which ORB to use. I do like however to allow to use every ORB you like. Michael [Still posted to hackers as I'm not sure I'm subscribed to interfaces. Will check that later.] -- 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!
On Mon, 16 Nov 1998, Michael Meskes wrote:
> On Sat, Nov 14, 1998 at 09:49:48PM -0400, The Hermit Hacker wrote:
> > For instance, I already have MICO installed because of
> > koffice...I'd prefer not to have to install *another* one because I want
> > to use it for PostgreSQL.
>
> Hey Marc, this shouldn't be the reason to decide which ORB to use. I do like
> however to allow to use every ORB you like.
Was just an example...*roll eyes* *grin*
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Mon, 16 Nov 1998, Michael Meskes wrote:
> On Sat, Nov 14, 1998 at 09:57:18PM -0400, The Hermit Hacker wrote:
> > Koffice is in alpha stages right now, screen shots look good...I
> > just finally got a clean compile of mico under FreeBSD, so next is to get
> > koffice done up too...
>
> So what software do they use? In particular of course I'd like to know
> whether they use PostgreSQL as DB backend.
None, right now...I could be wrong though, haven't been able to
get it up and running yet :(
> > And, yes, they use an orb...mico, in particular :)
>
> But mico isn't used for the complete KDE system (/or is it?), whereas Gnome
> uses its ORB almost everywhere it seems.
From what Taral has investigatd and come up with, if we stick with
a 2.2 implementation of Corba (mico is only free implementation, that I am
aware of, tha tis fully 2.2 compliant...the rest are all 2.0 still), then
when the other ORBs, when they come up to speed (if?), making it workk
with them should be relatively easy.
According to what Taral has found out so far, 2.2's API is very
rigidly defined, whereas 2.0''s is left up to the implementator...
The end result I'd like to see if for PostgreSQL to be able to be
compiled against whatever implementation the installer wishes, as long as
they are 2.2 compliant...
Quite frankly, I want the *core* to be built around a complete
implementation...if someone is really hot on ORBit, and wants to add in
compatibility code so that it will work with ORBit, so bit it...but I want
the *core* to be 2.2 clean/compliant...and mico is the only ORB out there
at this point in time that will allow that...Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> I *like* that attitude! I'm researching CORBA now, to see if ORBit is
> sufficient for our needs.
Please look at ILU too... Predates CORBA, but has CORBA compatibility
and lots of history/development. afaik ORBit doesn't have broad
multi-language support, but I suppose we could use ILU for clients and
ORBit for the backend server, which is already C.
- Tom
On Mon, Nov 16, 1998 at 03:42:45PM -0400, The Hermit Hacker wrote: > From what Taral has investigatd and come up with, if we stick with > a 2.2 implementation of Corba (mico is only free implementation, that I am > aware of, tha tis fully 2.2 compliant...the rest are all 2.0 still), then > when the other ORBs, when they come up to speed (if?), making it workk > with them should be relatively easy. I agree that we should go with 2.2. > The end result I'd like to see if for PostgreSQL to be able to be > compiled against whatever implementation the installer wishes, as long as > they are 2.2 compliant... Yes. > Quite frankly, I want the *core* to be built around a complete > implementation...if someone is really hot on ORBit, and wants to add in > compatibility code so that it will work with ORBit, so bit it...but I want > the *core* to be 2.2 clean/compliant...and mico is the only ORB out there > at this point in time that will allow that... I still think eventually PostgreSQL win run on ORBit on most systems. :-) 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!
On Tue, 17 Nov 1998, Michael Meskes wrote:
> On Mon, Nov 16, 1998 at 03:42:45PM -0400, The Hermit Hacker wrote:
> > From what Taral has investigatd and come up with, if we stick with
> > a 2.2 implementation of Corba (mico is only free implementation, that I am
> > aware of, tha tis fully 2.2 compliant...the rest are all 2.0 still), then
> > when the other ORBs, when they come up to speed (if?), making it workk
> > with them should be relatively easy.
>
> I agree that we should go with 2.2.
>
> > The end result I'd like to see if for PostgreSQL to be able to be
> > compiled against whatever implementation the installer wishes, as long as
> > they are 2.2 compliant...
>
> Yes.
>
> > Quite frankly, I want the *core* to be built around a complete
> > implementation...if someone is really hot on ORBit, and wants to add in
> > compatibility code so that it will work with ORBit, so bit it...but I want
> > the *core* to be 2.2 clean/compliant...and mico is the only ORB out there
> > at this point in time that will allow that...
>
> I still think eventually PostgreSQL win run on ORBit on most systems. :-)
>
Possibly...which makes a few assumption though...1st is that ORBit
ever catches up to mico and 2 that mico doesn't speed up as it matures :)
Personally, the only thing that I care about is that *we* aren't
the ones that are scrambling to catch up to the 2.2 standard...we have a
clean (albeit slow) solution to work with now, let the other
implementations catch up to that...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Tue, 17 Nov 1998, Michael Meskes wrote:
> > Quite frankly, I want the *core* to be built around a complete
> > implementation...if someone is really hot on ORBit, and wants to add in
> > compatibility code so that it will work with ORBit, so bit it...but I want
> > the *core* to be 2.2 clean/compliant...and mico is the only ORB out there
> > at this point in time that will allow that...
>
> I still think eventually PostgreSQL win run on ORBit on most systems. :-)
Appendum...why do you use PostgreSQL? Speed or features? :)
ORBit is to MICO as MSQL is to POstgreSQL :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Marc G. Fournier writes: > On Tue, 17 Nov 1998, Michael Meskes wrote: > > > > Quite frankly, I want the *core* to be built around a complete > > > implementation...if someone is really hot on ORBit, and wants to add in > > > compatibility code so that it will work with ORBit, so bit it...but I want > > > the *core* to be 2.2 clean/compliant...and mico is the only ORB out there > > > at this point in time that will allow that... > > > > I still think eventually PostgreSQL win run on ORBit on most systems. :-) > > Appendum...why do you use PostgreSQL? Speed or features? :) > > ORBit is to MICO as MSQL is to POstgreSQL :) > Ok, but I think the other sense of the question is even more interesting: why do people use MSQL instead of PostgreSQL? My point is that while pg beats msql hands down on features, speed is important enough to a lot of users that they choose msql instead. If we had more speed, we would have even more success than we do now. -dg David Gould dg@informix.com 510.628.3783 or 510.305.9468 Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612 The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world.
On Tue, Nov 17, 1998 at 09:23:58AM -0400, The Hermit Hacker wrote: > Possibly...which makes a few assumption though...1st is that ORBit > ever catches up to mico and 2 that mico doesn't speed up as it matures :) Right. These assumptions are made on a) Mico was thought to be an educational project and b) ORBit has the financial backing of RedHat. But of course I might be wrong. :-) > Personally, the only thing that I care about is that *we* aren't > the ones that are scrambling to catch up to the 2.2 standard...we have a > clean (albeit slow) solution to work with now, let the other > implementations catch up to that... Totally agreed. 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!
On Tue, Nov 17, 1998 at 09:25:10AM -0400, The Hermit Hacker wrote: > Appendum...why do you use PostgreSQL? Speed or features? :) Both! :-) > ORBit is to MICO as MSQL is to POstgreSQL :) I would think PostgreSQL is better than MICO in their respective area. :-) 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!