Re: GEP / C++ bindings ...

[Evan Carew <carew pobox com>]

Mike,

With respect to the technical arguments:
    Sometimes, the best technical arguments don't help one bit when it 
comes to a particular technology's adoption. It appears from your 
discussion below this is not a favorite topic of the current developers, 
however, I have a feeling that this may be a distinction without a 
difference. That is to say, what use is the most favorable technical 
direction (C only IDL) if only a small fraction of the potential market 
is using it?

Naturally, this means it will only benifit my corporate customers    
Like most of the other respondents here on this subject, I too am 
waiting on the adoption of C++ into the IDL prior to using Orbit in my 
nect project. Should it not be there, no problem, I'll just grit my 
teeth and reccomend a commercial product with a C++ binding (the norm) 
and keep my code proprietary (I'd like to release it as GPL). Naturally, 
I'd prefer to release my code to the community, however, without decent 
support from the Orbit IDL compiler, two groups of people loose here. 
First, the CORBA adopters loose a good source for GPLed functionality, 
and second, the open source community looses access to new applications.

As this duscussion proceeds, I'll be watching it closely as I am very 
interested in its outcome. Quite selfishly, as an impatient adopter, I 
hope this discussion comes to a conclusion quickly so I know which 
technical direction to take in the near future.

BTW, in case it hasn't been said recently. I do think this is a nice 
product worthy of use by anyone interested in a decent GPLed CORBA 
implementation with good performance (as long as you want to do your 
work in C).

Michael Meeks wrote:

>	With respect that has precisely no bearing on the technical aspect of
>whether we integrate the C++ bindings with ORBit2. Yes, if we want to
>add the bindings to the core platform, then it's a different angle
>really. Yes, I can see that adding the C++ to the core will help
>adoption.
>
>	What I'm looking for are better, technical arguments for doing that.
>I'm not in the business of driving adoption, I want the best technical
>decision long term, and thus good arguments for it. But I'll post the
>proposal as it is now perhaps.
>
>	Regards,
>
>		Michael.
>
>  
>