OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-c-cpp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ISSUES 82-85: W. Cox PR Comments



I propose we use the following text as the response to W. Cox's Public Review comments:

The SCA C-C++ TC thanks you for review and comments on the SCA Client and Implementation Model for C++ Specification.

Our responses to your comments are below.

[1] Editorial Line 52

Reference should be made to the typographical conventions for conformance assertions in this section. The Assembly document's handling of conformance statements and highlighting is excellent; I recommend that this (and all other SCA specs) follow that example.


A reference to Section 11 belongs in the typographic conventions section.


Response:
These changes will be made and are being tracked by issue CCPP-82 (http://www.osoa.org/jira/browse/CCPP-82).

[2] Technical Section 2.1.1ff

Some of this reads like reinvention of aspects of CORBA with remote services. A compare and contrast (perhaps in a separate architectural white paper) with other remoting techniques would make this choice easier to review. Is this indeed a reinvention? Or is it a simple acknowledgement that remotable and local services share some similarity in the SCA model? More architectural discussion would make that evaluation easier.

Response:
Local and remotable interfaces for SCA are defined in the Assembly specification and are independent of the component implementation technology/language.  The C++ Client and Implementation specification only defines how interfaces are designated remotable or local for C++ and interprets the requirements for remotable interfaces for C++.

Because the concepts of local and remotable interfaces for SCA are defined in the Assembly specification and can be applied to any SCA component implementation technology/language, a overall architectural discussion of SCA local and remotable interfaces and how the compare to other technologies would need to be addressed by the SCA Assembly TC
.

[3] Editorial lines 1152-1154

Part of the text is a heading; repair.

Response:
This is a PDF conversion problem and will be addressed in subsequent published drafts.

[4] Technical Lines 1641-1644

It's quite clear (given the context, though not stated) why Friend classes MUST NOT be used; it's less clear why Macros should not be.  If this is an implementation-based architectural decision, perhaps it should be mentioned


Response:
The limitations on macros are being re-evaluated.  This section will be updated with either more specific limitations or a discussion of the limitations.  This is being tracked by issue CCPP-84 (http://www.osoa.org/jira/browse/CCPP-84).

[5] Technical General

It's hard to tell where to start reading the SCA specifications; I've concentrated on Assembly and Java/C++ as that's what I intend to use.  Many of the architectural choices, and the specification details, would be more clear if mentioned in a separate white paper or linkable publication. The architectural choices made in the design of SCA are interesting in of themselves, but would inform the reader, implementer, and user as they work with the specifications.

Response:
The SCA C & C++ TC recommends reading and understanding the Assembly specification before trying to read and understand the C++ client and implementation specification.  The Assembly specification defines the core concepts, architecture and constructs for SCA.  There are some additional concepts defined in the Policy Framework that are also needed to understand parts of the C++ client and implementation specification.  The C++ client and implementation specification defines how the concepts, architecture and constructs  of the Assembly specification and Policy Framework are to be implemented by a SCA runtime that supports C++ component implementations and how C++ component implementations use the concepts, architecture and constructs.

A discussion of the architectural choices for SCA as a whole would need to be done by the Assembly TC as these choices are intentionally implementation technology/language independent.  If there are architectural choices specific to the to the implementation of SCA in either C++ or C that you believe would benefit from further discussion, the SCA C & C++ TC would welcome that input..


[6] Editorial Lines 1758-1766

A reference to the conformance items and Appendix F would make this section read better.

Response:
This change will be made and is being tracked by issue CCPP-82 (http://www.osoa.org/jira/browse/CCPP-82).

[7] Editorial General

"Error! Reference source not found" at lines 991 and 1413. Please repair.


Response:
These changes will be made and are being tracked by issue CCPP-82 (http://www.osoa.org/jira/browse/CCPP-82).


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]