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: [sca-c-cpp] NEW ISSUE: Review types supported in Service interfaces


Target: C++ C&I Specification CD03

 

Description:

The conformance items in section 8.1 and 8.2 are inconsistent with the WSDL mapping rules defined in section 10.1.3.

 

Proposal:

 

8.1 Local Services

 

The return type and types of parameters of a member function of a local service MUST be one of:

  • Any fundamental or compound types as defined by C++. [CPP80001]

 

8.2 Remotable Services

 

For a remotable service being called by another service the data exchange semantics is by-value.  The return type and types of the parameters of a member function of a remotable interface MUST be one of:

  • Any of the C++ types specified in Section 10.3.1.  These types may be passed by-value, by-reference, or by-pointer.  Unless the member function and client indicate that they allow by-reference semantics (See Section 2.1.2), copy will be explicitly created by the runtime for any parameters passed by-reference or by-pointer.
  • An SDO DataObjectPtr instance.  This type may be passed by-value, by-reference, or by-pointer.  Unless the member function and client indicate that they allow by-reference semantics (See Section 2.1.2), copy will be explicitly created by the runtime for any parameters passed by-reference or by-pointer, a deep-copy of the DataObjectPtr will be created by the runtime for any parameters passed by-value, by-reference, or by-pointer. [CPP80002]

 

Rationale:

 

  • Since a local service invoke is the equivalent of invoking the function directly, I’m not aware of any reasons why there should be any restrictions on the parameters of the function.  For example, if we support passing a class instance, I’m not sure why we would not be able to support passing a union.  If there are restrictions that the runtime should enforce, then additional clarifications will be needed.
  • Discussion of const/non-const doesn’t seem relevant.  There were no situations where we would allow passing a value if it was const, but not if it was non-const.  const is a factor in determining the mapping of the parameters to/from WSDL types, however that is covered in a different section.

 



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