Thread

1. Re: [HACKERS] CORBA STATUS

   Oliver Elphick <olly@lfix.co.uk> — 1999-11-10T15:42:53Z

   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.
   
   
   -- 
         Vote against SPAM: http://www.politik-digital.de/spam/
                    ========================================
   Oliver Elphick                                Oliver.Elphick@lfix.co.uk
   Isle of Wight                              http://www.lfix.co.uk/oliver
                  PGP key from public servers; key ID 32B8FAA1
                    ========================================
        "But thanks be to God, which giveth us the victory 
         through our Lord Jesus Christ."     
                                 I Corinthians 15:57 
   
   
   
   

2. Re: [HACKERS] CORBA STATUS

   Lamar Owen <lamar.owen@wgcr.org> — 1999-11-10T15:57:51Z

   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
   
   

3. Re: [HACKERS] CORBA STATUS

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-11-10T17:23:47Z

   > 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.
   
   Right.
   
   > I can force the installation of a particular ORB through dependencies, but
   > that seems messy to me.
   
   Not so bad, but I understand your point.
   
   > I CAN produce multiple sets of packages -- but that's going to cause all
   > manner of confusion for users.
   
   Right. Not worth the effort.
   
   > Is it possible in the CORBA context to do what Oliver mentioned with a 'pg_orb'
   > abstraction layer to a generic CORBA-enabled postgreSQL??
   
   Maybe, as a second step. The first step (which we are a *long* ways
   away from; getting a consensus on how to proceed will take a miracle)
   will be to get an implementation using one Orb with the feature set we
   want.
   
   > 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.
   
   This may not be what people want to hear, and may not be what turns
   out, but imho and imle ("little experience" ;)...
   
   Corba is really intended to allow clients and servers implemented with
   different Orb products to interoperate transparently. It has very
   carefully stayed away from over-specifying exactly *how* a particular
   client or server would be implemented for a particular Orb.
   
   The header file conventions, or lack thereof, is a good example of
   this. I'm familiar with a couple of the C++ Orbs. Mico produces a
   single header file per interface, while TAO produces two. Hmm, it just
   dawned on me that I might be able to jigger the output file names from
   TAO's IDL compiler to make the names line up with Mico. Will get back
   to you on this detail :)
   
   Anyway, if Corba is in our future, I would think that we would work
   with a single Orb for the server-side implementation, at least at
   first. Once we are up and running, then we talk about how to slip in
   someone's favorite other Orb.
   
   For clients, we will have to pick and choose depending on the language
   and features required. For example, TAO has portability and some
   realtime features and optimizations that make it the *only* choice for
   our realtime systems at work. But Mico has a nice TCL binding, so we
   are using that to implement some TCL GUIs for commanding and telemetry
   interfaces.
   
   Not a big deal, and we quickly got over the *flap arms all over* "Oh
   no! This Orb doesn't support language X!!!!".
   
   btw, the Orb which has more language bindings than any other is ILU.
   ILU predates Corba by several years, but it has evolved to support the
   Corba standard in many areas.
   
   Corba was primarily intended to decouple clients from servers.
   Inter-orb transportability at the source code level was a secondary
   concern, though the Corba standard, or at least some of the
   conventions used in the open-source implementations, may be converging
   a bit to help with the source portability. And the biggest
   source-level portability concern, the call-level interfaces, is not a
   problem.
   
   As we are introducing Corba to new users at work (we've got O(20)
   programmers who will be using it on our testbeds and ground
   implementations for optical interferometers), I emphasize the
   following:
   
   1) Corba makes distributed computing easy, in that clients (the
   calling programs) call servers (the subroutines) as though they were
   local to the client. But in fact they could reside anywhere.
   
   2) Specifying interfaces through IDL is a *great* way to design
   systems. If you have the interface, then you know what you need to
   implement. From then on, clients and servers, or callers and call-ees,
   can be implemented independently. If we end up with Corba in our
   server, then we could/should start specifying our internal interfaces
   with IDL also.
   
   3) Since clients and servers are decoupled through well-defined
   interfaces, and since these interfaces can be decoupled "on the wire",
   you have great flexibility in how you mix and match Orb products to
   implement clients and servers. But afaik all of the Orbs have a "short
   circuit" which will allow you to build Corba-enabled routines written
   with that Orb into the same image, without taking a hit at runtime to
   marshall/unmarshall/network/etc.
   
   One in an occasional series... ;)
   
                    - Thomas
   
   btw, I'm guessing that the way to get Corba going is to have a code
   freeze/fork, and have a few people work on demonstrating Corba using
   that frozen version. Then we re-merge later if the Corba demo was a
   success *and* if Corba is what we want in the main-line product. That
   could happen during our 7.x series of releases, and if the world wants
   Corba, we could mainstream it for v8.0.
   
   -- 
   Thomas Lockhart				lockhart@alumni.caltech.edu
   South Pasadena, California
   
   

4. Re: [INTERFACES] Re: [HACKERS] CORBA STATUS

   Bruce Stephens <bruce@cenderis.demon.co.uk> — 1999-11-10T23:37:38Z

   "Oliver Elphick" <olly@lfix.co.uk> writes:
   
   > 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.
   
   It probably makes sense to try to get things working with one ORB, and
   then see if it's worth generalising.  I'd guess ORBit is a good one to
   start with since it's C-based, and it's pretty small: if I have to
   install an extra package on my machine just to run PostgreSQL, I'm not
   going to mind ORBit, whereas TAO might annoy me (IIRC, TAO is quite
   big; I may be thinking of another ORB, though).  ORBit does IIOP, I
   believe, so that covers GNOME and KDE people.
   
   

5. Re: [INTERFACES] Re: [HACKERS] CORBA STATUS

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-11-11T15:35:58Z

   > It probably makes sense to try to get things working with one ORB, and
   > then see if it's worth generalising.  I'd guess ORBit is a good one to
   > start with since it's C-based, and it's pretty small: if I have to
   > install an extra package on my machine just to run PostgreSQL, I'm not
   > going to mind ORBit, whereas TAO might annoy me (IIRC, TAO is quite
   > big; I may be thinking of another ORB, though).  ORBit does IIOP, I
   > believe, so that covers GNOME and KDE people.
   
   Yeah, TAO might annoy you; it takes 1.3GB of disk space to build,
   though much less once built ;)
   
                        - Thomas
   
   -- 
   Thomas Lockhart				lockhart@alumni.caltech.edu
   South Pasadena, California
   
   

6. Error on db recovery..

   Stephen Martin <stephen@sealteam.demon.co.uk> — 1999-11-11T21:00:57Z

   Hello,
   I am attempting to recover a database previously secured with pg_dump,
   however on attempting to restore using 
   
   pgsql < db_security_file 
   
   I get the following error(s)
   
   
   ERROR:  tbl_breeders relation already exists
   
   I have removed all data tables and user from the database,
   what am I over looking?
   
   Stephen 
   
   
   
   

7. Re: [INTERFACES] Error on db recovery..

   Sergio A. Kessler <ser@perio.unlp.edu.ar> — 1999-11-11T22:04:20Z

   "Stephen Martin" <stephen@sealteam.demon.co.uk> el día Thu, 11 Nov 1999 
   13:00:57 -0800, escribió:
   
   >Hello,
   >I am attempting to recover a database previously secured with pg_dump,
   >however on attempting to restore using 
   >
   >pgsql < db_security_file 
   
   bad, bad ...
   
   go to /usr/doc/postgres and read ...
   
   
   Sergio