pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Lamar Owen <lamar.owen@wgcr.org>
To: Oliver Elphick <olly@lfix.co.uk>
To: The Hermit Hacker <scrappy@hub.org>
Cc: pgsql-hackers@postgreSQL.org
Cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [HACKERS] CORBA STATUS
Date: Wed, 10 Nov 1999 10:57:51 -0500
Message-ID: <99111011093307.00555@lorc.wgcr.org> (raw)
In-Reply-To: <199911101542.PAA05115@linda.lfix.co.uk>
References: <199911101542.PAA05115@linda.lfix.co.uk>

On Wed, 10 Nov 1999, Oliver Elphick wrote:
> The Hermit Hacker wrote:
>   >> Is there any reason configure couldn't handle this?
>   >
>   >As simple as a '--with-corba=mico' configure option ... or, I would think?
>  
> From the point of view of a package maintainer, I would much prefer a
> solution that separated the choice of Orb from the main build.
> 
> If the choice goes into configure, I will have to pick a single Orb and
> build the Debian package for that, or else make packages for every
> Orb that Debian supports.  It would be better if I could build a generic
> Orb-enabled PostgreSQL and produce a little pg-orb connection library
> for each Debian-supported Orb.

The same issue is true for the RPM's -- which ORB?  If I'm on RedHat Linux, the
choice of ORB is going to depend upon the choice of desktops -- KDE or GNOME. 
ORBit is packaged standard for GNOME -- KDE 2 is going to use something else --
now, my understanding of CORBA is quite limited -- Thomas, you have far more
experience, as you are actively developing CORBA stuff.  If I choose to install
just KDE, KDE's ORB is going to be installed -- if I install GNOME, ORBit is
going to be installed. If I install both (the default), both ORB's will be
resident.

I can force the installation of a particular ORB through dependencies, but
that seems messy to me.

I CAN produce multiple sets of packages -- but that's going to cause all
manner of confusion for users.

Is it possible in the CORBA context to do what Oliver mentioned with a 'pg_orb'
abstraction layer to a generic CORBA-enabled postgreSQL??

It may seem like Oliver and I are getting the cart before the horse, but
the strategic decision of how to integrate CORBA into the system is going to
have wide-ranging repercussions for integrators.

 --
 Lamar Owen
WGCR Internet Radio
1 Peter 4:11



view thread (30+ messages)  latest in thread

Message-ID: <99111011093307.00555@lorc.wgcr.org>
Permalink:  ../99111011093307.00555@lorc.wgcr.org/
Also on:    postgresql.org/message-id/99111011093307.00555@lorc.wgcr.org

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-interfaces@postgresql.org
  Cc: lamar.owen@wgcr.org, olly@lfix.co.uk, scrappy@hub.org, pgsql-hackers@postgreSQL.org
  Subject: Re: [HACKERS] CORBA STATUS
  In-Reply-To: <99111011093307.00555@lorc.wgcr.org>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox