Re: [boost] CORBA iimplementation for Boost interest?

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2008-04-01 18:37:46

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