CORBA in fifty words or less:
   
   CORBA is an architecture which specifies how to:
     - define the method signatures of an object 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, and platforms.
   
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 an OID), the rationale for PostgreSQL+CORBA will be hard to
    understand.
   
    The short version goes like this:
   
    Think of a database table as a "typedef" of a data structure, with each
    row representing a malloc'ed instance of that structure type.  The
    database provides for persistant storage, and concurrent data access,
    but with a considerable access overhead: 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 strings from 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 to read 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 always available for relational queries.
    
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.
    
    GNOME then adopted ORBit, which has two wins: it's in C, and (this is
    the biggy) it has provisions to shortcut parameter marshalling,
    transmission, authentication, reception, and demarshalling--if the client
    stub and server skeleton are in the same address space, and both stub
    and skeleton permit this.

    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 intermediate all 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, 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.

    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.


		-Michael Robinson


Sat, 14 Nov 1998 01:19:49 +0800 (GMT)
Michael Robinson <robinson@public.bta.net.cn>
More PostgreSQL+CORBA
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 


Fri, 13 Nov 1998 13:39:17 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] More PostgreSQL+CORBA
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 form
	UPDATE 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

Fri, 13 Nov 1998 17:52:39 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] More PostgreSQL+CORBA 
> >  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

Sat, 14 Nov 1998 02:17:12 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] More PostgreSQL+CORBA
> 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, Pennsylvania 19026

Fri, 13 Nov 1998 22:57:46 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] More PostgreSQL+CORBA
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 


Sat, 14 Nov 1998 01:18:40 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] More PostgreSQL+CORBA
> 	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, Pennsylvania 19026

Sat, 14 Nov 1998 02:34:04 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] More PostgreSQL+CORBA
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!



Sat, 14 Nov 1998 14:19:21 +0100
Michael Meskes <meskes@usa.net>
Re: [HACKERS] More PostgreSQL+CORBA
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 


Sat, 14 Nov 1998 10:19:17 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] More PostgreSQL+CORBA
> > 	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, Pennsylvania 19026

Sat, 14 Nov 1998 10:38:08 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] More PostgreSQL+CORBA
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

Sat, 14 Nov 1998 11:19:19 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] More PostgreSQL+CORBA 
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

Sat, 14 Nov 1998 19:40:36 +0200
Hannu Krosing <hannu@trust.ee>
Re: [HACKERS] More PostgreSQL+CORBA
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

Sat, 14 Nov 1998 20:01:39 +0200
Hannu Krosing <hannu@trust.ee>
Re: [HACKERS] More PostgreSQL+CORBA
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

Sat, 14 Nov 1998 20:04:56 +0200
Hannu Krosing <hannu@trust.ee>
Re: [HACKERS] More PostgreSQL+CORBA
> 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, Pennsylvania 19026

Sat, 14 Nov 1998 13:48:48 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] More PostgreSQL+CORBA
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!



Sat, 14 Nov 1998 19:53:51 +0100
Michael Meskes <meskes@usa.net>
Re: [HACKERS] More PostgreSQL+CORBA
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!



Sat, 14 Nov 1998 19:54:41 +0100
Michael Meskes <meskes@usa.net>
Re: [HACKERS] More PostgreSQL+CORBA
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


Sat, 14 Nov 1998 14:25:36 -0600 (CST)
Taral <taral@cyberjunkie.com>
Re: [HACKERS] More PostgreSQL+CORBA
> > > 
> > > 	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
--------------------------------------------



Sat, 14 Nov 1998 23:40:21 +0000 (AST)
Duane Currie <dcurrie@sandman.acadiau.ca>
Re: [HACKERS] More PostgreSQL+CORBA
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 


Sat, 14 Nov 1998 21:49:48 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] More PostgreSQL+CORBA
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 


Sat, 14 Nov 1998 21:51:41 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] More PostgreSQL+CORBA
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 


Sat, 14 Nov 1998 21:55:27 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] More PostgreSQL+CORBA
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 


Sat, 14 Nov 1998 21:57:18 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] More PostgreSQL+CORBA
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 


Sat, 14 Nov 1998 22:05:43 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] More PostgreSQL+CORBA
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


Sat, 14 Nov 1998 21:24:18 -0500 (EST)
Todd Graham Lewis <tlewis@mindspring.net>
Re: [HACKERS] More PostgreSQL+CORBA
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


Sat, 14 Nov 1998 21:29:10 -0500 (EST)
Todd Graham Lewis <tlewis@mindspring.net>
Re: [HACKERS] More PostgreSQL+CORBA
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 


Sat, 14 Nov 1998 22:38:34 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] More PostgreSQL+CORBA
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.


Sun, 15 Nov 1998 00:29:47 -0600
"Taral" <taral@cyberjunkie.com>
RE: [HACKERS] More PostgreSQL+CORBA
On Sun, 15 Nov 1998, Taral wrote:

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

	See Bruce's post...discussion is moved to pgsql-interfaces...

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


Sun, 15 Nov 1998 02:41:46 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
RE: [HACKERS] More PostgreSQL+CORBA
> 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.

No, the IDL-to-language mappings are precisely defined by the CORBA 2.0
specification. However we do need a C to C++ thunking layer, as I said in a
previous post (that may have gotten lost in the e-mail cloud). The C++ API
as defined by CORBA 2.0 is quite different in certain areas (structs
replaced by classes, etc.)

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

The initial proof-of-concept will be a libpq wrapper. Later, we will code a
full alternate to the frontend, eventually hoping to have the FE/BE protocol
replaced with CORBA... (afaik)

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

We hope to be able to export objects with a Row interface, for example,
which effectively refer to a single row in the database. That way expensive
queries of the type 'UPDATE table SET column = data WHERE pkey = value' are
avoided.

Taral


Sun, 15 Nov 1998 08:43:05 -0600
"Taral" <taral@cyberjunkie.com>
RE: [HACKERS] More PostgreSQL+CORBA
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!



Mon, 16 Nov 1998 07:49:31 +0100
Michael Meskes <meskes@usa.net>
Re: [HACKERS] More PostgreSQL+CORBA
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!



Mon, 16 Nov 1998 12:31:31 +0100
Michael Meskes <meskes@usa.net>
Re: [HACKERS] More PostgreSQL+CORBA
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 an
 ORB, 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 
> 
> 

Mon, 16 Nov 1998 11:59:39 -0500
Jim Penny <jpenny@universal-fasteners.com>
Re: [HACKERS] More PostgreSQL+CORBA
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 


Mon, 16 Nov 1998 15:34:50 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] More PostgreSQL+CORBA
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 


Mon, 16 Nov 1998 15:42:45 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] More PostgreSQL+CORBA
> 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

Tue, 17 Nov 1998 02:38:24 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] More PostgreSQL+CORBA
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!



Tue, 17 Nov 1998 10:17:06 +0100
Michael Meskes <meskes@usa.net>
Re: [HACKERS] More PostgreSQL+CORBA
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 


Tue, 17 Nov 1998 09:23:58 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] More PostgreSQL+CORBA
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 


Tue, 17 Nov 1998 09:25:10 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] More PostgreSQL+CORBA
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.

Tue, 17 Nov 1998 11:20:33 -0800 (PST)
dg@informix.com (David Gould)
Re: [HACKERS] More PostgreSQL+CORBA
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!



Tue, 17 Nov 1998 20:24:15 +0100
Michael Meskes <meskes@usa.net>
Re: [HACKERS] More PostgreSQL+CORBA
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!



Tue, 17 Nov 1998 20:25:35 +0100
Michael Meskes <meskes@usa.net>
Re: [HACKERS] More PostgreSQL+CORBA