[omniORB] Re: [pygtk] Conflicting omniORBpy and PyORBit

[Jon Willeke]

I haven't used either ORB, so forgive me if I speak from a position of
ignorance.

With the introduction of the portable object adapter in CORBA 2.2, a
program may need minimal changes to use one ORB or another, but you
still need to choose at link time which to use.  The last time I looked
at Orbix and VisiBroker, building a program for both ORBs was not a
trivial matter.

If you want to keep the convenience of a top-level CORBA module, perhaps
you could adapt PyGTK's version selection code: use a .pth file to set
the default ORB.  A program that knows it needs a specific ORB could
still import it explicitly.

On Thu, 2003-08-14 at 04:07, ml wrote:
> On Thu, Aug 14, 2003 at 02:56:27PM +0800, James Henstridge wrote:
> > since apps may:
> > 
> >    * include stubs/skeleton files generated for a particular ORB
> >    * rely on special features of a particular ORB
> >    * need to interoperate with other bits of code using a particular
> >      ORB (this is the case for gnome programs wishing to manipulate in
> >      process Bonobo objects, which is why it can't use omniORB).
> 
> That exactly was the point: I have to have pyORBit installed
> for certain GNOME applications and I have to have omniORBpy
> installed for my own applications.  It is not possible to
> replace one ORB with another.  omniORBpy does not support
> Bonobo, pyORBit does not support omniINSPOA etc.  We have
> different ORBs for a reason.
> 
> Maybe, Duncan and James, you can agree on not to provide a
> "global" CORBA.py and PortableServer.py anymore.