Re: [boost] CORBA iimplementation for Boost interest?

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2008-04-04 08:14:51

vicente.botet wrote:
> 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.

Not quite. An IDL to C++ compiler has no meaning outside the realm of a 
particular ORB, as it needs to generate code (not only the user-visible 
'C++ binding') that ties into the ORB internals.

I agree that writing / porting an ORB is mostly independent of working 
on the C++ binding...at least if the design is right. It is true that 
the effects of changes to the C++ binding may reach deep into the ORB 
internals, but ideally that would be well separated. It depends on the 
target ORB.

Finally, as the topic came up, too: rewriting an IDL compiler requires a 
frontend (IDL parser) and a backend (ORB-specific code generator). I'll 
bring up the same argument here: I don't see much value in rewriting the 
IDL parser, just because we can. Take the omniidl tool that ships with 
omniORB: it is very well designed (internal AST representation generated 
by a bison/flex/C++-based parser and a Python-based code generator) and 
it's straight forward to simply provide a new backend generating code 
for a new and experimental C++ binding. (It already has two backends to 
generate C++ and Python bindings for the current omniORB.)

So, I'd rather see a focus on a new C++ binding instead of constantly 
getting side-tracked into tangential projects that I believe don't 
provide as much value to this community.

>>> 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.

That's not what I'm saying. A new binding is independent of the old one, 
and adding support for it to an existing ORB requires both, changes to 
the ORB itself (what that means depends on the design of the given ORB), 
as well as changes to the code-generating part (the 'backend') of the 
IDL-to-C++ compiler.

> 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.

That would be good indeed, but again, is much more a concern of an ORB 
implementor (which I hope boost will not become, as large as it already is).

>> 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.

Sure, implementing a new binding requires the ability to change the ORB. 
But does that imply that the ORB should be part of and be implemented in 
, boost ?

> As there is enough work for all and more, please can we construct together 
> each one on its prefered project.

I'm not telling anybody what to work on. I'm just concerned that, if 
boost reaches into even more domains, it will loose focus and be even 
harder to maintain. (Of course, if boost was more modular all this would 
be much less of a concern.)

>> 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?

To me this whole project of experimenting with a new C++ binding is more 
of a sandbox project anyways, that would profit from the experience of 
the boost community with the C++ language. So, in the end, an actual 
implementation could very well be contributed to whatever ORB was used 
to do the experimentation with.

Regards,
                Stefan

-- 
       ...ich hab' noch einen Koffer in Berlin...