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. _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
