${taskforce.name} Avatar
  1. OMG Task Force

2nd RPC over DDS 1.0 FTF — Closed Issues

Open Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

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