> 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
