Stefan Seefeld wrote:
Jonathan Biggar wrote:
So there appears to be some interest, and even more interest if it leads to developing a new more modern C++ binding for CORBA. But having an implementation of the current binding would be a huge start for that.
I don't quite agree. In particular, I think the phrasing above is quite a bit misleading: I wouldn't characterize an ORB as an 'implementation of a C++ binding'. And I also don't agree that a new ORB implementation is required as a prerequisite for a new C++ binding.
The reason I'm pointing this out is that I don't see any value in yet another ORB. Lots of time has been spent on existing ones to get decent performance, etc., and I think it's just naive and foolish to start all over, just to be able to pretend that this one is built with boost. Yet another case of Not-Invented-Here ?
Pick a good, free, ORB (the two choices that immediately come to mind are omniORB and TAO), and try to make modifications so it can be used with an alternate C++ binding. I think this would be a much more reasonable plan to move forward.
Stefan, I'm not going to implement a new ORB, I already have one that has been under development for over 10 years, and it provides several CORBA features that are not implemented in omniORB or TAO, such as the polling asynchronous invocation model, a complete implementation of valuetypes, and more of the Messaging QoS policies. And from my experience, much of an ORB implementation is pretty intricately tied into the C++ binding. Redevelopment of a new binding will touch a very large part of the ORB source code anyway. Having an ORB that uses the Boost Thread and ASIO libraries also means applications that use those boost libraries can easily use an ORB too without integration problems. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org