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

[Christian Reis]

On Thu, Aug 14, 2003 at 02:56:27PM +0800, James Henstridge wrote:
> If importing CORBA isn't always going to work, is it ever a good idea to 
> import the module?  If it is never a good idea to import CORBA, then 
> should ORBs ever provide a toplevel module by that name?
> 
> This definitely sounds like a problem with the spec.  I've got no idea 
> when the next version of the standard is likely to be made available, so 
> it might be worth coming up with some guidelines/clarifications we can 
> agree on.

I agree completely -- the spec is broken in this sense (and I said it
back in the orbit-python days when we had similar problems). 

James has an excellent rationale for it (and experience with conficts
that were raised by us having a module with the same name for
incompatible versions of PyGTK).

> In the above reasoning, I am assuming that applications will just run 
> with "any available ORB".  I think this is a fairly safe assumption, 
> since apps may:

James, don't you really mean "I am assuming that applications *won't*
run with `any available ORB'"? At least that's what the points below
suggest to me.

>    * 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).

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL