[Pipet Devel] Choice of ORB implementations

[Brad Chapman]

Jeff wrote:
> What is omniORB written in then?  C++?

Yup. Apparently (from searching the archives) the gnome people were 
interested in using omniORB when they were looking for an ORB 
implementation, but the omniORB developers were mostly interested in 
developing a high quality C++ ORB (although that has sinced changed 
since they now have python bindings :)

>> 3. Naming service: It seems like using the naming service might be a
>> good bet for maintaining a list of available VSH implmementations (I
>> think Jeff has described this before as a kind of domain name 
service
>> that maps vsh implementations to their names (ie. Jeff's computer)).
> 
> And the actual nodes contained therein.  We need a directory service 
of a
> sort.

    Well, the problem I see with this is that only certain nodes may 
be available to certain clients, and I was thinking that you'd have 
to authenticate with a remote connection so that connection can know 
what nodes to make available to you (based on your login). This goes 
back to something I was talking about earlier about specific 
authentication of nodes. This is a lot different then the directory 
service you are talking about.
    I think that the trading service (not implemented in ORBit) is 
designed for allowing searching for objects based on the service types 
that they offer. Maybe something like this could be utilized for 
searching for a "public" set of nodes. 

> My big concern is licensing.  But I guess both are GNU L/GPL, right?

Yup, omniORB is L/GPL.

> Did you decide on which orb to use?

For now, we're starting with ORBit. Jarl already has his code based 
around this (although I had to make him give up using gnorba :-< ) and 
I figured that you would like it best (seeing how it is associated 
with Gnome :-). It will be fairly easy to switch around since the 
python bindings are standardized (you can run diff on the two 
clients--Fnorb and orbit-python--in vsh-corba to see how similar they 
are), so we'll see what happens.

>> Does anyone see a workaround for the threading and binding problems 
I
>> mention above? How can we reconcile this? Do we need, ugh, two
>> ORB implementations?
> 
> Definitely not.

Well... we'll see how things go with ORBit. For now, I'm all with it, 
but I am very worried about the fact that it is not multithreaded and 
think that might hamper things later. Plus I really like omniORB and 
they have a smooth set of python bindings :-) Jarl found a page with 
patches to make ORBit multithreaded (http://goethe.ira.uka.de/~wilhelm
i/corba/orbit-mt.html). These patches are for 0.5.0 (and orbit-python 
requires 0.5.1) but I am going to try to work with these as much as 
possible and give ORBit the best shot. It may end up surprising me and 
I too may fall under the spell of the greatness of gnome :-)

Brad