From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-04-04 04:59:12
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.
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
> 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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk