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
- From: Bryan Aupperle <aupperle@us.ibm.com>
- To: sca-c-cpp@lists.oasis-open.org
- Date: Mon, 13 Jul 2009 09:17:12 -0400
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]