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

[James Henstridge]

On 3/08/2003 3:18 AM, Duncan Grisby wrote:

>On Friday 1 August, James Henstridge wrote:
>
>  
>
>>>The only issue for packagers is how to deal with the top-level CORBA
>>>(and PortableServer, etc.) modules. One solution would be to install
>>>them only if they are not already there from a different ORB.
>>> 
>>>      
>>>
>>Yep, and that seems to be a problem for distributors wishing to package 
>>multiple Python ORBs.  I am not sure what the right choice here is.
>>    
>>
>
>One option would be for each ORB package to be split in two, one with
>the main distribution, and one with just the top-level CORBA.py etc.
>That way, you could choose to install several main ORB packages, and
>just one "default ORB" package or something like that.
>  
>
I was thinking a bit about this last statement of yours, and I don't 
think it is a very satisfactory way to leave things.

I know of no Linux distributions which are in a position to make a 
decision about what their "default ORB" should be.  They are more likely 
to package an ORB if they want to ship applications that use it.

More over, if you are writing an application that uses a particular ORB, 
and you want to make it work on as many systems as possible you wouldn't 
be able to just type "import CORBA", since your program would break on 
systems which picked a different "default ORB".

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.


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:

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

 James.

-- 
Email: james at daa.com.au
WWW:   http://www.daa.com.au/~james/