1. OMG Mailing List
  2. Remote Procedure Call over DDS 1.1 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: dds-rpc-rtf
  • Issues Count: 3

Issues Descriptions

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

  • Key: DDSRPC11-3
  • Status: open  
  • Source: Twin Oaks ( 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 ( 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

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

  • Key: DDSRPC11-1
  • Status: open  
  • Source: Real-Time Innovations ( 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: Tue, 28 Aug 2018 23:45 GMT