Sender: lockhart@hub.org
Message-ID: <3828388D.3EC63B4B@alumni.caltech.edu>
Date: Tue, 09 Nov 1999 15:06:53 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: Brian E Gallew <geek+@cmu.edu>, pgsql-hackers@postgreSQL.org,
	pgsql-interfaces@postgreSQL.org
Subject: Re: [HACKERS] CORBA STATUS
References: <Pine.BSF.4.10.9911091011530.2296-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > > imho it will be extremely difficult to find an ORB which could be
> > > injected directly into the Postgres server. It would likely reduce the
> > > number of platforms Postgres runs on, and would not be considered
> > > acceptable.
> > On the other hand, this is where the power of configure comes into
> > play.  Assuming we have servers for multiple ORBs, configure can look
> > to see what's installed (TAO, Orbit, whatever) and then build only
> > that server.

In the long run, that would be neat. In the short run, the details of
each ORB vary considerably wrt, for example, the names and numbers of
#include files. So it would complicate the code to try bringing along
two ORBs at the beginning. We might expect the ORBs to converge a bit
over time, so this will be easier later.

> ACtually, I believe Thomas was referring to those platforms that we
> currently support that have no ORBs available to them...being a "purely C"
> server so far, how many of our currently supported platforms are we going
> to cut off with this?

Don't know, and it doesn't matter (yet). We shouldn't avoid the issue
without someone looking at it further just because we *might* lose
some platforms; better to push it farther as a demonstration at least
before deciding that it isn't a possibility.

Anyway, I know that at least one ORB, TAO, runs on many more types of
platforms than Postgres does (e.g. VxWorks, Lynx, Solaris, NT, ...),
though Postgres runs on more Unix-style platforms. But that particular
ORB is not a good candidate for us, for reasons I already mentioned
(C++, large build size, poor configure support).

                    - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California