The Hermit Hacker <scrappy@hub.org> 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?
>
>	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?

	http://www.corba.org/vendors/index.html

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

This is my plan:
	1. Wrap the current libpq API in CORBA, as a proof of concept
	2. Implement a static row-level interface, which maps PostgreSQL
	   types to CORBA types
	3. Design a fully dynamic interface, complete with Interface
	   Repository integration with the PostgreSQL type system
	4. Implement the design

Number one shouldn't take very long (a few weeks, once I get the whole
CORBA development thing sorted out).  Two shouldn't take much longer.
Three and four is anybody's guess, and, as I mentioned earlier, four
depends on currently unimplemented sections of ORBit.

	-Michael


Sun, 15 Nov 1998 12:24:19 +0800 (GMT)
Michael Robinson <robinson@public.bta.net.cn>
Re: [HACKERS] More PostgreSQL+CORBA
On Sun, 15 Nov 1998, Michael Robinson wrote:

> This is my plan:
> 	1. Wrap the current libpq API in CORBA, as a proof of concept
> 	2. Implement a static row-level interface, which maps PostgreSQL
> 	   types to CORBA types
> 	3. Design a fully dynamic interface, complete with Interface
> 	   Repository integration with the PostgreSQL type system
> 	4. Implement the design
> 
> Number one shouldn't take very long (a few weeks, once I get the whole
> CORBA development thing sorted out).  Two shouldn't take much longer.
> Three and four is anybody's guess, and, as I mentioned earlier, four
> depends on currently unimplemented sections of ORBit.

	If this is to be implemented, please do *not* make it dependent on
any one version of Corba...IMHO, that is like telling everyone they must
installed GCC 2.8.1 as their compiler to compile PostgreSQL...it takes the
choice out of ppls hands and forces them to support one implementation.

	If it takes using Mico, at this point in time, to implement this
*properly*, so be it...but however it is implemented, it has to be done in
such a way that it is as generic as possible so that the choice of what
CORBA implementation is left up to the person running the end-system, not
the developer because he had a bias/preference.

	And, ya, I currently have a bias, and that is towards MICO, since,
by your own admission, ORBit's only supports a sub-set of CORBA...there is
absolutely no reason why our CORBA implementation should be tied to the
development pace of one particular implementation...

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


Sun, 15 Nov 1998 00:51:05 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] More PostgreSQL+CORBA
Ok, moved to interfaces as suggested

Maybe it would be a good idea to strip CC:s ?

Michael Robinson wrote:
> 
> 
> >       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...
> 
> This is my plan:
>         1. Wrap the current libpq API in CORBA, as a proof of concept

Add 1.A. here: extend current FE<->BE interface to support prepared 
statements, at least to the level of SPI, maybe even _start_ from
"extended" 
SPI CORBA interface. "Extended" because SPI had same deficiences as 
well compared to the "main" FE<->BE protocol.

>         2. Implement a static row-level interface, which maps PostgreSQL
>            types to CORBA types

2.A. Define a standard way for CORBA'fying the postgresql 
user-defined types

>         3. Design a fully dynamic interface, complete with Interface
>            Repository integration with the PostgreSQL type system
>         4. Implement the design
>
> Number one shouldn't take very long (a few weeks, once I get the whole
> CORBA development thing sorted out).  Two shouldn't take much longer.
> Three and four is anybody's guess, and, as I mentioned earlier, four
> depends on currently unimplemented sections of ORBit.

I think, that we should start with an ORB that has C-interface 
'cause the rest of PostgreSQL is in C. 

The time will probably be better spent on implementing the 
unimplemented sections rather than writing a C to C++ wrapper 
(the part which should in theory be made unneccesary by CORBA !)

So supporting other language IDL mappings
(C++,java,python,ada,smalltalk,...) 
directly in backend seems not to be a very good idea

Of course we should support all C mappings.

------------------
Hannu

Sun, 15 Nov 1998 16:06:23 +0200
Hannu Krosing <hannu@trust.ee>
Re: [HACKERS] More PostgreSQL+CORBA