Re: GEP / C++ bindings ...

[Murray Cumming <murrayc usa net>]

On Fri, 2002-08-09 at 12:04, Michael Meeks wrote:

Please don't shaft us on this. We have accepted your timeframe and
worked towards your plan. People have actually stopped working on the
standalone ORBit/C++ because they are waiting for cpp to go into
mainstream ORBit2. However, we did know that you'd would need to get
release-team approval of it later.

2. Proposal
2.1 Internal API exposure
Since the C++ bindings involve using a fairly large amount of ORB
internal API, it is undesirable to split them from the ORB. These APIs
include the binary servant layout and idl-compiler interfaces. It's
possible that we could work exposing these.

I don't know. As I understand it you wanted to add it to ORBit itself
because this wasn't so easy, and so that you wouldn't have an extra API
to stabilize.

2.2 Packaging convenience
Introducing the C++ bindings into core ORBit2 may cause portability
problems, and while these can be obviated by a conditional build, this
seems problematic.

I don't see any problems. We want to be portable too. For instance,
gtkmm builds on Sun's Forte C++. In the event of a problem people can
fix it with a configure option.

2.3 API / ABI stability2. Proposal
The C++ bindings are however, immature and should not be considered ABI
stable, however - since they have to conform to the standard CORBA C++
binding perhaps this is no problem.

You should make it clear that the C++ APIs provided by ORBit would have
a different development schedule than the C APIs. That's possible
because the APIs are clearly separate, though the implementation is less
separate.
 
2.4 Maintenance
The C++ bindings would need a separate maintainer, but it would seem to
make some sense to have these modules in the same place.

That sense is (as above):
1. No need to support/stabilize a 3rd "internals" API.
2. More reuse of internals implementation.
3. Perhaps most importantly, it encourages development of the C++
bindings.

3. Issues Raised During Discussion2. Proposal
So far none.

People will complain about:
- Build time. It will be _slightly_ longer with the C++ stuff in there.
They wouldn't complain about the extra time if they didn't know that it
was caused by C++ code being in there.
- Portability. It will be fixed if it's a problem, and turned off if
it's unfixable.
 
-- 
Murray Cumming
murrayc@usa.net
www.murrayc.com