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