RE: [sdo] C++ Spec

[Bryan Aupperle <aupperle@us.ibm.com>]

I share many of your concerns.  There
a number of key differences between Java and C++ (and even more so with
procedural languages like C).  No annotations, as you point out, no
generic objects, no instance classes for base types (I have not yet had
sufficient time to consider an the implications of  the proposed use
of instance classes in determining type compatibility), etc.  We need
to be aware of these as we work on 3.0, if we want to be able to use SDOs
as a interoperable data format for exchanging messages between services.
 I suspect we may have to come to a point where we say there is an
SDO core with extensions that may not be possible to support in all languages.
 The goal need to be to have concepts treated as consistently as possible
in each of the languages.

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect

Research Triangle Park,  NC 
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com

"James Hart" <James.Hart@roguewave.com>

02/27/2008 03:58 PM

To	Bryan Aupperle/Raleigh/IBM@IBMUS
cc	<sdo@lists.oasis-open.org>
Subject	RE: [sdo] C++ Spec

Dr, Aupperle, thanks for responding.
 
The company I work for, Rogue
Wave Software, has an SDO product based largely on 2.+.  I would like
to be part of any discussions or work on translating what is done for 3.0
Java spec to a C++ equivalent.
 
My biggest concern at the moment
is that it seems like the new Java spec features will largely depend on
Java specific features.  Such as annotations and using Types generically
for creating data objects and interacting with POJOs and such, which aren’t
a trivial thing to implement in C++.  Basically, if it is a feature/concept
they want to use that is available because of the interpretive aspect of
the Java language it is not going to be so trivial to migrate the same
concept to C++ or any other non-interpretive languages.  In fact,
a lot of that behavior would need to be accomplished via code generation
and compile time and might even require additional interfaces to be implemented
by an end user.  Data won’t just be “plug and play” in those cases.
 I don’t really understand why there isn’t just a Spec that is language
independent and then Java, like all other language specs are driven by
that.  Especially if one of the big points of SDO is that it defines
a common interface cross language.  Has that principle changed, or
have I misinterpreted that as a goal when it really isn’t?  If that
was not the case, then should there be another committee all together to
determine a diverging spec for C++ if the desired concepts with the Java
version of SDO become incompatible?
 
Please, anyone chime in!
 
Thanks,
~James

---

From: Bryan Aupperle [mailto:aupperle@us.ibm.com]
Sent: Wednesday, February 27, 2008 12:15 PM
To: sdo@lists.oasis-open.org
Subject: Re: [sdo] C++ Spec
 

I have converted the 2.1 draft to the OASIS format and have been watching
the issues being transferred from the OSOA JIRA system to make sure that
they are not already addressed or duplicates, so you could say that I am
leading the C++ work (more by default than anything formal).

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect

Research Triangle Park,  NC 
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com

"James Hart" <James.Hart@roguewave.com>

02/27/2008 11:17 AM

To	<sdo@lists.oasis-open.org>
cc
Subject	[sdo] C++ Spec

 

Could I get information on who to contact that is currently leading the initiative for any new SDO C++ spec work?
 
Thanks,
 James