Hello, I think that there are atleast 3 CORBA related projects: Orb- Boostification of the Jonathan ORM implementation that was the origin of this thread (Maybe someone else want to boostify TAO+ACE) Idl2Cpp- Idl to C++ compiler NewCppBinding- New C++ binding on top of an existing ORB implementation (without Idl2Cpp compiler). These three projects can start in parallel and they are independent. One the NewCppBind start to make sens we will need to modify the Idl2Cpp for the new binding. The Orb implementation is interesting for atleast 4 rasions: * If the new c++ binding could be not possible without modification of the ORB back end. * The mapping could be facilitated when we can do some modification to the ORB back end. * Performances could imply that without been able to mody the ORB the new binding is not usable. * In addition, I think that the implementation of an ORB needs a lot of infrastructure that could finish as separated Boost libraries available to the boost community. For the momment I see that Jonathan wants to start with the Boostification of its ORB implementation and then Idl2Cpp using Boost libraries. Someone wants to take the responsability to start the NewCppBinding project? Some comments follows. Regards _____________________ Vicente Juan Botet Escriba From: "Stefan Seefeld" <seefeld@sympatico.ca> Subject: Re: [boost] CORBA iimplementation for Boost interest?
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.
You are maybe right. You can always implement a new C++ binding on top of the standard one. This is IMO a separated project that allow to experiment already with existings ORB implementations. One of the thinks that this new binding should support is IMO that both bindings can live together on the same application, allowing a smooth transition.
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 ?
I'm sure that when doing this task we will confront with some problems that could have a better solution if we don't need to map to the standard binding. And there it will be really interesting to be able to modify an ORB implementation. As there is enough work for all and more, please can we construct together each one on its prefered project.
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.
What do you will do with the omniORB or TAO modifications? Will you integrate them its current releases?