

-----Original Message-----
From: Dan Gowin 
Sent: Thursday, November 12, 1998 10:46 AM
To: 'Cary B. O'Brien'
Subject: RE: [HACKERS] Re: CORBA Interface


All,
	I agree with below. The ORB should be a seperate
daemon from the backend. Not only will the stability
of the backend be affected if the ORB is placed in the
backend, but performance will also suffer. The ORB should
be developed as a seperate daemon which -could- be placed
on a seperate server to increase performance. Also remember,
however the ORB is designed, it will consume alot of CPU
and memory resources within the server.

D.

-----Original Message-----
From: Cary B. O'Brien [mailto:cobrien@access.digex.net]
Sent: Thursday, November 12, 1998 10:00 AM
To: pgsql-hackers@hub.org
Subject: [HACKERS] Re: CORBA Interface



1) A corba interface sounds interesting.  I wish I had time
   to investigate corba further.  

2) Applixware proports to be able to access corba objects.  I guess
   this means it can import/export corba IDLs, and talk over IIOP?
   I haven't tried it out.

3) I'm not sure that the interface needs to be part of the backend.
   Most of the structure information can be obtained from the pg_ 
   tables.  Having a separate process would be safer for the overall
   stability of the backend.  Am I missing something?

In any case, it seems very worth investigating.

-- cary


Thu, 12 Nov 1998 10:57:15 -0500
Dan Gowin <DGowin@avantec.net>
FW: [HACKERS] Re: CORBA Interface
> The ORB should be a seperate
> daemon from the backend. Not only will the stability
> of the backend be affected if the ORB is placed in the
> backend, but performance will also suffer. The ORB should
> be developed as a seperate daemon which -could- be placed
> on a seperate server to increase performance. Also remember,
> however the ORB is designed, it will consume alot of CPU
> and memory resources within the server.
>> 3) I'm not sure that the interface needs to be part of the backend.
>>    Most of the structure information can be obtained from the pg_
>>    tables.  Having a separate process would be safer for the overall
>>    stability of the backend.  Am I missing something?

I'm not sure I follow this. We would be looking to the ORB to replace
*all* on-the-wire communications between frontends and backends, to take
advantage of the data marshalling, security and directory layers of
Corba. So we would want the ORB to infest at least parts of the current
Postgres backend to eliminate the current socket/IP interface, right?

Or would we only be using the ORB to present a sort-of-thin client
layer, to replace libpq for an app? Are there other RDBMSes which claim
to have a Corba interface? What does the API look like?

I've been looking at Corba for other projects, and have worked with DCE
a bit in the past. I would guess that the interface between, say, psql
and a server would have psql asking for a postgres server through the
corba API, and the server side would provide a fresh backend as a
result. The API would include methods to allow queries, etc, and methods
to return results...

                           - Tom

Thu, 12 Nov 1998 16:30:00 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: FW: [HACKERS] Re: CORBA Interface