Re: [boost] CORBA iimplementation for Boost interest?

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-04-04 04:59:12

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_at_[hidden]>
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?