Re: [sca-c-cpp-comment] Comments on Public Review Draft 01 - C++

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

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
OASIS SCA C-C++ TC
Chair

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

William Cox <wtcox@comcast.net>

06/23/2009 11:01 PM

To	sca-c-cpp-comment@lists.oasis-open.org
cc
Subject	[sca-c-cpp-comment] Comments on Public Review Draft 01 - C++

Comment numbers in square brackets. References are
to the PDF.

[0] The specification is excellent overall. I found few errors, and the
specifcation raised relatively few questions.

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

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

The specification is quite clear and seems effective, though I've not 
tried to write to it.

[3] Editorial lines 1152-1154

Part of the text is a heading; repair.

[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

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

[6] Editorial Lines 1758-1766

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

[7] Editorial General

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



--
This publicly archived list offers a means to provide input to the
OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: sca-c-cpp-comment-subscribe@lists.oasis-open.org
Unsubscribe: sca-c-cpp-comment-unsubscribe@lists.oasis-open.org
List help: sca-c-cpp-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/sca-c-cpp-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-c-cpp
Join OASIS: http://www.oasis-open.org/join/