RPC Over DDS Avatar
  1. OMG Specification

RPC Over DDS — All Issues

  • Acronym: DDS-RPC
  • Issues Count: 18
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSRPC11-5 Common Types contains invalid IDL DDS-RPC 1.0 open
DDSRPC11-1 Mapping of one single Topic per Service does not work well with DDS Security DDS-RPC 1.0 open
DDSRPC11-4 Consider replacing @Choice annotation with XTYPES 1.2 unions DDS-RPC 1.0 open
DDSRPC11-3 Remove the 'default' case in Requst and Return union types DDS-RPC 1.0 open
DDSRPC11-2 Errors in non-normative IDL of section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types DDS-RPC 1.0 open
DDSRPC_-9 Collisions in the implied IDL DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-15 missing attribute exception specification mapping DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-13 Potentially redundant UnknowEx DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-1 Clarifications and simple technical corrections DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-7 Editorial corrections in the spec document DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-11 modules in IDL DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-25 QoS library name with profile filename DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-23 return code mapping in IDL2C++11 DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-21 Why do we need @Choice DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-19 Annotation Scope DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-17 potential hash collisions DDS-RPC 1.0b1 DDS-RPC 1.0 Duplicate or Merged closed
DDSRPC_-5 Inconsistent ParameterIDs DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-3 Review comments Remedy IT on RPC4DDS DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed

Issues Descriptions

Common Types contains invalid IDL

  • Key: DDSRPC11-5
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    IDL identifiers may not reuse the same names (disregarding case) of types already in scope. This is a problem for "instanceName" in the RPC spec:

    struct RequestHeader {
      SampleIndentity_t requestId;
      InstanceName instanceName;
    };
    

    And SampleIndentity_t is misspelled. It should be SampleIdentity.

  • Reported: DDS-RPC 1.0 — Wed, 16 Jun 2021 21:32 GMT
  • Updated: Wed, 16 Jun 2021 21:32 GMT

Mapping of one single Topic per Service does not work well with DDS Security

  • Key: DDSRPC11-1
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    This issue has also been entered into DDS-Security as the solution could also involve changes to that specification. See:
    https://issues.omg.org/browse/DDSSEC12-31

    DDS-RPC maps each DDS-Service to a single (unkeyed) Topic-pair (request topic & reply Topic).

    DDS-Security provides access control per Topic and per Instance (Key). Moreover, the builtin plugins only provide access control per Topic.

    With these mappings is it not possible to configure access control per operation/method in the service. This is a common requirement for many service definitions.

    One way to overcome this would be to provide a mapping where each a Service would map to multiple Topic pairs. E.g. one Topic pair per method/operation. That way it would be possible to separately grant permissions to call operations on a service or to implement operations on a service.

    The mapping of a Topic pair per method/operation would also setting different Qos per operation...

    Alternatively one could

  • Reported: DDS-RPC 1.0 — Tue, 28 Aug 2018 23:45 GMT
  • Updated: Wed, 24 Jun 2020 17:36 GMT

Consider replacing @Choice annotation with XTYPES 1.2 unions

  • Key: DDSRPC11-4
  • Status: open  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    The DDS-RPC added a @Choice annotation (see 7.5.1.2.1.1 @Choice Annotation) to indicate a Structure with the "single-member" semantics of a union. As stated in the aforementioned section the reason was:

    Using unions to indicate which operation is being invoked is brittle. Operations in an interface have set semantics and have no ordering constraints. Union, however, enforces strict association with discriminator values, which are too strict for set semantics. Further, use of unions leads to ambiguities in case of multiple inheritance of interfaces.

    However XTYPES 1.2 enhanced unions which now support inheritance and are not so brittle anymore. For this reason it makes sense to re-evaluate this decision.

    An advantage of using unions (beyond avoiding a extraneous annotation) is that their API is better oriented to identifying the one branch that is present; whereas in the case of structures there is no standard API available to determine which member is present other than iterating over every member. This would be unnatural for processing the RPC calls.

  • Reported: DDS-RPC 1.0 — Tue, 24 Sep 2019 13:26 GMT
  • Updated: Tue, 24 Sep 2019 13:26 GMT

Remove the 'default' case in Requst and Return union types

  • Key: DDSRPC11-3
  • Status: open  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    Section 7.5.1.1.4 Mapping of Interfaces to the Request Topic Types, and Section 7.5.1.1.5 Mapping of Interfaces to the Reply Topic Types, each define a union and specify that the union should have a 'default:' case.

    This makes it difficult to extend the union to support interface inheritance.

    The 'default:' case should be removed.

  • Reported: DDS-RPC 1.0 — Wed, 12 Dec 2018 23:42 GMT
  • Updated: Wed, 12 Dec 2018 23:42 GMT

Errors in non-normative IDL of section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types

  • Key: DDSRPC11-2
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    Section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types cotntains the following IDL:

    @Choice @Autoid
    struct RobotControl_command_Result { 
        RobotControl_command_Out result;
    };@Choice @Autoid
    struct RobotControl_stop_Result { 
        RobotControl_getSpeed_Out result;
    };
    };@Choice @Autoid
    struct RobotControl_setSpeed_Result {
          RobotControl_setSpeed_Out result;
          TooFast toofast_ex;
    };
    };@Choice @Autoid
    struct RobotControl_getSpeed_Result {
          RobotControl_getStatus_Out result;
    };
    

    This IDL is not correct. It contains extra "};" preceding the @Choice annotations in several places.

    In Addition in IDL42 all annotations are lower case. Specifically @autoid is defined there.

    Therefore the correct IDL would be:

    @choice @autoid
    struct RobotControl_command_Result { 
        RobotControl_command_Out result;
    };
    
    @choice @autoid
    struct RobotControl_stop_Result { 
        RobotControl_getSpeed_Out result;
    };
    
    @choice @autoid
    struct RobotControl_setSpeed_Result {
          RobotControl_setSpeed_Out result;
          TooFast toofast_ex;
    };
    
    @choice @autoid
    struct RobotControl_getSpeed_Result {
          RobotControl_getStatus_Out result;
    };
    
  • Reported: DDS-RPC 1.0 — Thu, 6 Sep 2018 00:04 GMT
  • Updated: Thu, 6 Sep 2018 00:04 GMT

Collisions in the implied IDL

  • Key: DDSRPC_-9
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Section 8.3.1.2
    What about collisions in the implied IDL types, hashes, etc. If a collision appears what are the rules to follow, because client and service could be developed by independent groups and DDS vendors which should than follow the same rules

    What when the user has an interface with a user defined parameter with the name return_ and there is a return value? This leads to a clash in the generated struct

    What when the user has an operation remoteEx in his interface IDL?

    What if there is a clash between the const hash name and user defined IDL?

    What is the behavior of @autoid with a hash-collision? Also what happens when operations are reordered at the moment there is a hash-collision? Couldn't that break interoperability?

  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:54 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Collision resolutions incorporated in multiple sections

    The following collision resolution techniques have been incorporated

  • Updated: Tue, 12 Jul 2016 14:44 GMT

missing attribute exception specification mapping

  • Key: DDSRPC_-15
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    For the result struct, with IDL attributes it is possible to define separate exceptions with the set and the get of the attribute (getraises/setraises), this is not reflected in the result mapping

  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:56 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Added mapping for interface attributes and collision resolution

    Added section 7.5.1.1.3

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Potentially redundant UnknowEx

  • Key: DDSRPC_-13
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Section 8.5.1.1.3
    For the result unions, why is not the unknownEx be part of the RobotControl_Return union as described on page 25, that would save a lot of union members. This exception is generic and independent of the operation.

  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:55 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Removed UnknowEx

    Removed UnknownEx from Section 7.5.1.1.4

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Clarifications and simple technical corrections

  • Key: DDSRPC_-1
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    This issue is a subset of the DDSRPC-1 issue reported by Remedy.

    IDL zip (mars/14-11-05)
    rpc_types.idl:
    Uses the RTI specific top-level annotation. Also top-level is illegal according to the IDL grammar.
    Uses anonymous types
    robot.idl:

    In the 4rd paragraph it mentions “asynchronous invocations”, but this is not mentioned in 8.2.2.1, how do asynchronous invocations look like with the function call style in the basic profile?

    Section 8.2.3
    Where in this document is the API defined to get the request id at both sides for implicit or explicit?

    Section 8.2.1
    Why include space as part of user_def_alpha_num?

    Section 8.5.1.1.1
    Why is SequenceNumber_t not using an “unsigned long long”. It is now a struct but there is no explanation in the specification about high and low

    Section 8.5.1.1.2
    Why not put the implied types into a nested module so that they don't pollute the user IDL module and resulting code, doxygen documentation, etc

    Section 8.5.1.1.4
    Why not put the implied types into a nested module so that they don't pollute the user IDL module and resulting code, doxygen documentation, etc

    What is the error when the remote service is not there (for example not running or not reachable), which exception do I get back?
    What when the service crashes during handling of the request, what kind of error do I get back, what is the timeout? How can configure timeouts etc?

    Section 8.7.1.3
    What about changing the exception specification of an operation?
    Section 8.8.2
    Not a legal IDL struct definition, struct has to be removed from its members
    Section 8.10.1
    What about the library name RTI DDS currently supports. It is very helpful to have multiple QoS profiles in one file and the spec should define how this works

  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 18:09 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Added clarifications to the spec document or provided justifications

    Added clarifications to the spec document or provided justifications below.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Editorial corrections in the spec document

  • Key: DDSRPC_-7
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The following content is a subset of DDSRPC-1 issue reported by Remedy.

    Document (mars/14-11-02)
    Section 4
    reference to CORBA should be updated to CORBA v3.3
    reference to IDL should be updated to CORBA v3.3
    reference for DDS4CCM lacks document number
    reference for DDS-Cxx-PSM and DDS-Java-PSM should be updated to the formal version
    reference to github, how can we in the future pinpoint the exact version of the files mentioned, shouldn't the reference be more explicit about which version?
    reference to IDL 3.5 is lacking (used in section 8.3.1)
    Section 5
    Shouldn't there be a reference in section 4 for this quote?
    Section 8.1
    The spec talks about “communication patterns”, but in the context of UCM we are talking about “interaction patterns”, what about adopting the UCM term?
    Section 8.2.1
    Second paragraph, the fact that a content-based filter “is” used forces that everyone must do this (which is the most logical implementation), but shouldn't it be “could”
    In the second paragraph its says “the service implementation contains a data reader to read the method name”, but shouldn't it be “the service implementation contains a data reader which receives the request and after that reads the method name and the parameters.”

    Can't the diagram be placed after the first paragraph, it is now on the next page but we refer in text already to it).

    Third paragraph, at the end “are filtered out”.

    Section 8.2.3
    Isn't it better to keep the term “client” instead of introducing “requester”

    Section 8.2.5
    “ it is” instead of “It is”
    Section 8.3.1.2
    Use a reference to DDS-XTypes in the first paragraph, not in the 3rd
    Section xx

    Section xx
    The spec uses IDL anonymous types in some places, these are deprecated and prevented to our idea.
    Section 8.4
    “by the used,”??
    Section 8.4.2.3
    Reference error
    Section 8.4.3.3
    Reference error
    Section 8.5.1.1.2
    Space missing before “shall” on 3rd line

    Section 8.5.1.1.4
    Typo Non-noramtive

    Section 8.7.1
    Evolution should be evolution.
    Section 8.8.2.1/8.8.2.2
    Add a reference to where in this specification this language binding is provided

  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 18:01 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Correction have been incorporated

    The suggested editorial corrections have been incorporated in the updated specification document.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

modules in IDL

  • Key: DDSRPC_-11
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Section 8.3.1
    What about the support for modules in IDL. In larger systems it will almost get impossible to guarantee the uniqueness of an interface when multiple parts are integrated. Also with an UCM approach modules are the way to group interfaces together. The module is now completely left which could lead to problems in a larger system. To our idea a change of an interface to another module is something that RPC4DDS shouldn't silently adapt to

  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:51 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    include module hierarcy to fully qualify interfaces

    Replaced "unqualified" with "fully-qualified".

  • Updated: Tue, 12 Jul 2016 14:44 GMT

QoS library name with profile filename

  • Key: DDSRPC_-25
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Section 8.10.1
    What about the library name RTI DDS currently supports. It is very helpful to have multiple QoS profiles in one file and the spec should define how this works

  • Reported: DDS-RPC 1.0b1 — Thu, 5 Nov 2015 00:00 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Add optional library name at the end of the filename URL

    The URL may end with an optional library name. The profile filename and library_name are separated by a #. For example, file://path/to/filename#library_name.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

return code mapping in IDL2C++11

  • Key: DDSRPC_-23
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    section 8.5.2
    What is the mapping for the return codes when the regular IDL to IDL2C+, IDL2C+11, etc language mappings are used

  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:59 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    *Clarified the mapping of remote error codes to IDL2C++11 *

    Reworded section 7.5.2 as follows.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Why do we need @Choice

  • Key: DDSRPC_-21
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    We still doubt the need to introduce @choice, with a union with the hash as discriminator value the is always one value active and there is a quick lookup at runtime. It works for the basic profile so why introduce this new IDL behavior for the enhanced one?

  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:58 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Clarification provided as the rationale

    The following clarification has been provided as the rationale behind @Choice

    It is our intent to support interface inheritance (including multiple inheritance) as cleanly as possible using the tools provided by DDS-Xtypes in the enhanced service profile. @Choice is added in response to that.
    The following must be satisfied.
    1. A requester must be able invoke operations in a service implementing an "evolved" version of the same interface (with more operations or fewer exceptions, etc.)
    2. A base interface requester must be able to invoke operations in a service implementing a derived interface.
    3. In case of multiple inheritance, order of base interfaces should have no impact with respect to interoperability of the derived interface. I.e., interface is a set of operations and has no ordering between.
    Mapping to union requires selection of a discriminator, which has natural ordering. The language mapping rules have to have complex rules to ensure that implicit ordering does not come in the way of supporting interface evolution. For instance, the order in which the base interfaces are listed must be deterministic to get the same union discriminators to all operations. Similarly, the order exceptions must also be deterministic for the operation-specific *_Result structures. (see 7.5.1.2.3 and 7.5.1.2.5)
    The @choice annotation which implies all members are optional and the type is mutable has simple assignability semantics. I believe it has "strong assignability". It really simplifies analysis of interface interoperability and evolvability.
    A common argument in favor of union is its ability to jump to the right member with a single lookup. That's conceptually true but I'm not sure if the mapping of @choice is slow. It requires finding a non-null pointer in an array of pointers. It appears like a micro-optimization.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Annotation Scope

  • Key: DDSRPC_-19
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Section 8.5.1.2.1
    Shouldn't the dds::rpc scope be used when the annotations are used?

  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:58 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    added a normative idl file with annotation definitions

    Added a normative idl file with annotation definitions. See attached rpc_annotations.idl

  • Updated: Tue, 12 Jul 2016 14:44 GMT
  • Attachments:

potential hash collisions

  • Key: DDSRPC_-17
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    What if there is a clash between the const hash name and user defined IDL?

    What is the behavior of @autoid with a hash-collision? Also what happens when operations are reordered at the moment there is a hash-collision? Couldn't that break interoperability?

  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:57 GMT
  • Disposition: Duplicate or Merged — DDS-RPC 1.0
  • Disposition Summary:

    Duplicate of DDSRPC_-9

    This issue is already addressed in Duplicate of DDSRPC_-9

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Inconsistent ParameterIDs

  • Key: DDSRPC_-5
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    ParameterIDs for the extended SubscriptionBuiltinTopicData elements should be 0x80, 0x81, 0x82. Reported by Clark Tucker (Twin Oaks)

  • Reported: DDS-RPC 1.0b1 — Tue, 25 Aug 2015 17:30 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Updated PIDs

    @extensibility(MUTABLE_EXTENSIBILITY)
    struct PublicationBuiltinTopicDataExt : PublicationBuiltinTopicData

    { @ID(0x00540x0080) string<256> service_instance_name; @ID(0x00550x0081) GUID_t related_datareader_key; @ID(0x00560x0082) sequence<string<256>> topic_aliases; }

    ;
    @extensibility(MUTABLE_EXTENSIBILITY)
    struct SubscriptionBuiltinTopicDataExt : SubscriptionBuiltinTopicData

    { @ID(0x00540x0080) string<256> service_instance_name; @ID(0x00550x0081) GUID_t related_datawriter_key; @ID(0x00560x0082) sequence<string<256>> topic_aliases; }

    ;

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Review comments Remedy IT on RPC4DDS

  • Key: DDSRPC_-3
  • Legacy Issue Number: 19693
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    This is not a 100% review, we focused on the basic profile together with the IDL and after receiving the initial comments of the AB and the fact that there is not one submission we didn't complete a detailed review. We didn't review the github code.

    IDL zip (mars/14-11-05)
    rpc_types.idl:
    Uses the RTI specific top-level annotation. Also top-level is illegal according to the IDL grammar.
    Uses anonymous types
    robot.idl:

    Document (mars/14-11-02)
    Section 4
    reference to CORBA should be updated to CORBA v3.3
    reference to IDL should be updated to CORBA v3.3
    reference for DDS4CCM lacks document number
    reference for DDS-Cxx-PSM and DDS-Java-PSM should be updated to the formal version
    reference to github, how can we in the future pinpoint the exact version of the files mentioned, shouldn't the reference be more explicit about which version?
    reference to IDL 3.5 is lacking (used in section 8.3.1)

    Section 5
    Shouldn't there be a reference in section 4 for this quote?

    Section 8.1
    The spec talks about “communication patterns”, but in the context of UCM we are talking about “interaction patterns”, what about adopting the UCM term?

    Section 8.2.1
    In the second paragraph its says “the service implementation contains a data reader to read the method name”, but shouldn't it be “the service implementation contains a data reader which receives the request and after that reads the method name and the parameters.”
    Can't the diagram be placed after the first paragraph, it is now on the next page but we refer in text already to it).
    Third paragraph, at the end “are filtered out”.
    Second paragraph, the fact that a content-based filter “is” used forces that everyone must do this (which is the most logical implementation), but shouldn't it be “could”
    In the 4rd paragraph it mentions “asynchronous invocations”, but this is not mentioned in 8.2.2.1, how do asynchronous invocations look like with the function call style in the basic profile?

    Section 8.2.3
    Isn't it better to keep the term “client” instead of introducing “requester”
    Where in this document is the API defined to get the request id at both sides for implicit or explicit?

    Section 8.2.5
    “ it is” instead of “It is”

    Section 8.3.1
    What about the support for modules in IDL. In larger systems it will almost get impossible to guarantee the uniqueness of an interface when multiple parts are integrated. Also with an UCM approach modules are the way to group interfaces together. The module is now completely left which could lead to problems in a larger system. To our idea a change of an interface to another module is something that RPC4DDS shouldn't silently adapt to

    Section 8.3.1.2
    Use a reference to DDS-XTypes in the first paragraph, not in the 3rd
    Section xx
    What about collisions in the implied IDL types, hashes, etc. If a collision appears what are the rules to follow, because client and service could be developed by independent groups and DDS vendors which should than follow the same rules

    Section xx
    The spec uses IDL anonymous types in some places, these are deprecated and prevented to our idea.

    Section 8.4
    “by the used,”??

    Section 8.2.1
    Why include space as part of user_def_alpha_num?

    Section 8.4.2.3
    Reference error

    Section 8.4.3.3
    Reference error

    Section 8.5.1.1.1
    Why is SequenceNumber_t not using an “unsigned long long”. It is now a struct but there is no explanation in the specification about high and low

    Section 8.5.1.1.2
    Space missing before “shall” on 3rd line
    Why not put the implied types into a nested module so that they don't pollute the user IDL module and resulting code, doxygen documentation, etc

    Section 8.5.1.1.3
    For the result unions, why is not the unknownEx be part of the RobotControl_Return union as described on page 25, that would save a lot of union members. This exception is generic and independent of the operation.
    What when the user has an interface with a user defined parameter with the name return_ and there is a return value? This leads to a clash in the generated struct
    For the result struct, with IDL attributes it is possible to define separate exceptions with the set and the get of the attribute (getraises/setraises), this is not reflected in the result mapping
    What if there is a clash between the const hash name and user defined IDL?

    Section 8.5.1.1.4
    Why not put the implied types into a nested module so that they don't pollute the user IDL module and resulting code, doxygen documentation, etc
    Typo Non-noramtive

    Section 8.5.1.2.1
    Shouldn't the dds::rpc scope be used when the annotations are used?
    We still doubt the need to introduce @choice, with a union with the hash as discriminator value the is always one value active and there is a quick lookup at runtime. It works for the basic profile so why introduce this new IDL behavior for the enhanced one?
    What is the behavior of @autoid with a hash-collision? Also what happens when operations are reordered at the moment there is a hash-collision? Couldn't that break interoperability?
    What when the user has an operation remoteEx in his interface IDL?

    Section 8.5.2
    What is the mapping for the return codes when the regular IDL to IDL2C+, IDL2C+11, etc language mappings are used
    What is the error when the remote service is not there (for example not running or not reachable), which exception do I get back?
    What when the service crashes during handling of the request, what kind of error do I get back, what is the timeout? How can configure timeouts etc?

    Section 8.7.1
    Evolution should be evolution.

    Section 8.7.1.3
    What about changing the exception specification of an operation?

    Section 8.8.2
    Not a legal IDL struct definition, struct has to be removed from its members

    Section 8.8.2.1/8.8.2.2
    Add a reference to where in this specification this language binding is provided

    Section 8.10.1
    What about the library name RTI DDS currently supports. It is very helpful to have multiple QoS profiles in one file and the spec should define how this works

  • Reported: DDS-RPC 1.0b1 — Thu, 18 Dec 2014 05:00 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Split issue in multiple smaller issues

    Split issue in multiple smaller issues.

  • Updated: Tue, 12 Jul 2016 14:44 GMT