Stefan Seefeld skrev:
vicente.botet wrote:
I think that a C++ CORBA implementation is a big deal. In addition a corba implemenation is not very useful without a minimal set of CORBA services.
I can imagine an experimental new C++ binding to be a worthy summer project. I have been using omniORB (http://omniorb.sourceforge.net/) heavily in the past, and I believe it to be easy enough to apply changes, in particular to its IDL compiler backend (which is written in Python), to generate code for such an alternative language binding.
In addition, some of the obvious changes are small and could be applied incrementally.
So, technically I don't see any reason not to try it, if someone's up to that task.
I agree that this aproach may be feasable to experiment with a new CORBA C++ language binding front end. Other CORBA implementations may also be used as back end in such an approach. TAO comes to my mind. I would probe interrest to support such a project from the developers of the candidate ORBs to see if they are willing to help. Note also that there has been work done on proposals for new CORBA language bindings for C++. I do not know the status or if anything has been made public or standardized in any way. The latest CORBA C++ language mapping at OMG.org is dated January 2008 but still contain the old binding stuff. No use of std::string or std::vector<T>, etc. that would make life so much simpler. I could not find a link, but I know I have seen postings on this in the past. Probably on the CORBA newsgroup. That is a good place to ask anyway. <wishfull_thinking> I would not mind at all if the C++ code I write for CORBA client or servers, i.e. the C++ in C++ to IDL mapping, was identical whether I used CORBA/IIOP or anything else of a number of other supported communication back-ends. I do not see the logic in why client or server source code should be concerned with details in the implementation of how data is transfered between them. Maybe differences need to be mapped to concepts much like std::iterator concepts so applications are hard-wired to requirements to the communication, not to the implementation as is more common today. </wishfull_thinking> -- bjørn