Received: from public.bta.net.cn (public.bta.net.cn [202.96.0.97])
	by hub.org (8.9.1/8.9.1) with ESMTP id MAA25335
	for <pgsql-hackers@postgresql.org>;
	Fri, 13 Nov 1998 12:20:25 -0500 (EST)
	(envelope-from robinson@public.bta.net.cn)
Received: (from robinson@localhost)
	by public.bta.net.cn (8.9.1/8.9.1) id BAA26341
	for pgsql-hackers@postgresql.org; Sat, 14 Nov 1998 01:19:49 +0800 (GMT)
Date: Sat, 14 Nov 1998 01:19:49 +0800 (GMT)
From: Michael Robinson <robinson@public.bta.net.cn>
Message-Id: <199811131719.BAA26341@public.bta.net.cn>
To: pgsql-hackers@postgresql.org
Subject: More PostgreSQL+CORBA

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