1. OMG Mailing List
  2. Data Distribution Service 1.5 RTF

Open Issues

  • Issues not resolved
  • Name: dds-rtf5
  • Issues Count: 74

Issues Summary

Key Issue Reported Fixed Disposition Status
DDS15-202 Relationship between begin/end coherent changes and presentation.coherent_access==true DDS 1.4 open
DDS15-201 No specification for unregister_type for TypeSupport interface DDS 1.4 open
DDS15-26 Missing APIs for (read|take)_instance_w_condition DDS 1.4 open
DDS15-200 Syntax for Topic Names DDS 1.4 open
DDS15-199 Typo DDS 1.4 open
DDS15-198 Add a write_sequence() operation to DataWriter DDS 1.4 open
DDS15-153 Definition of BuiltinTopicKey_t DDS 1.2 open
DDS15-197 Legal characters and length of Topic Name DDS 1.4 open
DDS15-183 Clarification of resource management DDS 1.2 open
DDS15-182 Clarification of create_multitopic behavior DDS 1.2 open
DDS15-181 Typo on description of class TopicDescription DDS 1.2 open
DDS15-179 Clarify behavior of register_type operation DDS 1.2 open
DDS15-176 Typo on descripton of "read" operation DDS 1.2 open
DDS15-175 Clarify behavior of "take" operation DDS 1.2 open
DDS15-173 Typo in description of "persistence" service reponsibility DDS 1.2 open
DDS15-172 Typo in Section: 2.1.3.14 DDS 1.2 open
DDS15-178 Clarification of instance_state -- Section: 2.1.2.5.1.3 DDS 1.2 open
DDS15-180 Behavior of multiple calls to create_topic -- Section: 2.1.2.3.2 DDS 1.2 open
DDS15-196 Clarify RxO behavior for DURABILITY Qos DDS 1.4 open
DDS15-195 Typo in section 2.2.2.5 Subscription Module DDS 1.4 open
DDS15-30 [DDS] Data types permissible as topic key fields DDS 1.2 open
DDS15-194 Coherent updates with best efforts DDS 1.4 open
DDS15-185 Invalid DURABILITY_SERVICE reference on the DataWriter DDS 1.1 open
DDS15-188 DATAWRITER_QOS_USE_TOPIC_QOS and DATAREADER_QOS_USE_TOPIC_QOS DDS 1.2 open
DDS15-171 Force KEEP_ALL to be RELIABLE Section: 2.1.3.18 DDS 1.2 open
DDS15-20 The DDS Specification should define legal DDS Topic Types DDS 1.4 open
DDS15-33 Deprecated usage of IDL in the DDS spec DDS 1.2 open
DDS15-45 Cancel coherent update DDS 1.2 open
DDS15-190 Specify Publishers with PRESENTATION access_scope GROUP should use same order for DataWriters DDS 1.4 open
DDS15-17 The get_sample_lost method seems to be part of the Subscriber class DDS 1.1 open
DDS15-16 Introduce new typedef DDS 1.2 open
DDS15-14 : #define HANDLE_TYPE_NATIVE long typedef HANDLE_TYPE_NATIVE InstanceHandle_t; DDS 1.2 open
DDS15-28 DDS Entities should have a name DDS 1.2 open
DDS15-37 DDS typos and omissions DDS 1.2 open
DDS15-44 Get entity enabled state DDS 1.2 open
DDS15-49 Semantics instance liveliness and ownership unclear DDS 1.2 open
DDS15-50 Add name attribute to Entity DDS 1.2 open
DDS15-184 create_contentfilteredtopic Method Prototype and Description Out DDS 1.2 open
DDS15-2 ContentFilteredTopics should be removed. Filtering belongs to DataReaders DDS 1.2 open
DDS15-22 Allow for more optimized list returned by get_datareaders() DDS 1.2 open
DDS15-29 All IDL should use local interfaces DDS 1.4 open
DDS15-186 subset of OMG IDL DDS 1.1 open
DDS15-3 Write with handle_nil underspecified DDS 1.2 open
DDS15-9 DDS specification should be more precise on NATIVE defines DDS 1.2 open
DDS15-10 Add DDS::STATUS_MASK_NONE DDS 1.2 open
DDS15-15 For ContentFilteredTopic::get_expression_parameters the argument name is not given in the spec DDS 1.2 open
DDS15-25 History and Reliability should be orthogonally independent concerns DDS 1.4 open
DDS15-32 No specific package definition for the entities of the model in case of JAVA language binding DDS 1.4 open
DDS15-43 DDS DCPS Issue: PRESENTATION=GROUP and QoS DDS 1.2 open
DDS15-51 Invalid DURABILITY_SERVICE reference on the DataWriter DDS 1.2 open
DDS15-177 Section: 2.1.2.5.3 DDS 1.2 open
DDS15-1 TypeSupport::get_type_name should be precisely specified DDS 1.2 open
DDS15-5 InstanceHandle_t/Domain ID DDS 1.2 open
DDS15-13 DDS defines Time_t with seconds as long, this is 32bit. This will give an issue after 2038 DDS 1.2 open
DDS15-21 Wrong definition of GROUPDATA_QOS_POLICY_NAME constant in IDL DDS 1.4 open
DDS15-34 'synchrobnous' and 'asynchronous' switched DDS 1.2 open
DDS15-36 DURABILITYSERVICE_POLICY_NAME DDS 1.2 open
DDS15-174 Section: 2.1.3 DDS 1.2 open
DDS15-4 Spec lacks definition regarding uniqueness of InstanceHandle_t DDS 1.2 open
DDS15-6 get_type_name, class or object method DDS 1.2 open
DDS15-27 behaviour of redefining multiple times the same topic with different QoS not clearly specified DDS 1.2 open
DDS15-52 DataReader semantics for historical data are insufficient DDS 1.2 open
DDS15-8 DDS should require to annotate IDL to indicate which IDL types are used for dds DDS 1.2 open
DDS15-12 Add new mask which will let DDS callback on the listener to gets its mask DDS 1.2 open
DDS15-46 Default built-in ReaderDataLifecycle values DDS 1.2 open
DDS15-47 Inconsistent lookup semantics DDS 1.2 open
DDS15-7 Add several with_profile methods DDS 1.2 open
DDS15-11 Extend Topic with method to retrieve key fields DDS 1.2 open
DDS15-23 When using GROUP access scope presentation QoS, allow for read/take outside of begin_access and end_access block DDS 1.2 open
DDS15-24 The compatibility rules for the Presentation QoS are too strict DDS 1.2 open
DDS15-31 Mapping of OMG IDL to C++ for DDS DDS 1.2 open
DDS15-35 Specify the allowed IDL Types within DDS Topic structs DDS 1.2 open
DDS15-48 Missing TypeSupport operations DDS 1.2 open
DDS15-187 Durability Implementation Description does not consider the role of partitions DDS 1.4 open

Issues Descriptions

Relationship between begin/end coherent changes and presentation.coherent_access==true

  • Key: DDS15-202
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We observe differences between DDS vendors related to begin/end_coherent_changes and presentation.coherent_access==true. The question is how begin_coherent_changes() should behave when presentation.coherent_access==false. Some vendors are silent and the operation just works, some return a RETCODE_ERROR saying begin_coherent_changes may only be called when presentation.coherent_access==true. To our idea the DDS spec should be precise so that users who separate code and qos (like DDS4CCM) do know what behavior they get

  • Reported: DDS 1.4 — Tue, 28 Mar 2017 15:05 GMT
  • Updated: Fri, 31 Mar 2017 16:55 GMT

No specification for unregister_type for TypeSupport interface

  • Key: DDS15-201
  • Status: open  
  • Source: DSTO ( Michael Mathers)
  • Summary:

    Currently there is no specification on the TypeSupport interface for an unregister_type operation as a companion to the register_type operation. This leads to variation between vendor implementations with respect to the lifecycle of type registrations. In the case of component-based architectural approaches it is desirable to be able to unload components to free resources. With no clear ability to unregister a type, it is not safe to unload component libraries while a container or manager of DDS infrastructure may still hold a reference to a no longer used type.

  • Reported: DDS 1.4 — Sun, 15 Jan 2017 23:13 GMT
  • Updated: Thu, 26 Jan 2017 21:03 GMT

Missing APIs for (read|take)_instance_w_condition

  • Key: DDS15-26
  • Legacy Issue Number: 16607
  • Status: open  
  • Source: Real-Time Innovations ( Kevin Jaeger)
  • Summary:

    For keyed topics, the core set of read or take APIs support read|take, read|take_instance, and read|take_next_instance.

    The corresponding set of API's for read or take with conditions only specified read|take_w_condition and read|take_next_instance_w_condition. The specification lacks the APIs for read|take_instance_w_condition.

    Lack of these APIs deprives the user from the ability to read or take from a specific instance while limiting the sample set to specific conditions.

  • Reported: DDS 1.4 — Fri, 14 Oct 2011 04:00 GMT
  • Updated: Thu, 22 Dec 2016 20:38 GMT

Syntax for Topic Names

  • Key: DDS15-200
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    For portability & interoperability it is necessary to know what the valid syntax of topic names can be, including valid characters. Some vendors support characters like '.' '/', ':' while others don't.

    The spec should make clear which characters are supported by all vendors

    Note that Appendix B does include a TOPICNAME syntax, but this section appears only related to content filters it is not clear if this would limit a Topic name in general. In Appendix B it says:

    TOPICNAME - A topic name is an identifier for a topic, and is defined as any series of characters ‘a’, ..., ‘z’, ‘A’, ..., ‘Z’, ‘0’, ..., ‘9’, ‘-’ but may not start with a digit.

    This seems limiting and also the "-" seems like an odd choice or perhaps a typo. "_" would be a more natural choice...

    Also it seems very restrictive to not allow things like "." or "/" or ":" given that large systems would want to organize their topic names and take advantage of this.

  • Reported: DDS 1.4 — Fri, 21 Oct 2016 14:29 GMT
  • Updated: Fri, 21 Oct 2016 14:37 GMT

Typo

  • Key: DDS15-199
  • Status: open  
  • Source: Netherlands Aerospace Centre ( Arnoud van Leeuwen)
  • Summary:

    Suspected typo in paragraph 4, last scentece:
    "In other words, the DataReader may miss some data-samples but it will never see the
    value of a data-object change from a newer value to an order value."

    Should the second to last word "order", not be: "older"? The context seems to suggest so.

  • Reported: DDS 1.4 — Fri, 19 Aug 2016 07:53 GMT
  • Updated: Fri, 19 Aug 2016 13:26 GMT

Add a write_sequence() operation to DataWriter

  • Key: DDS15-198
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The DDS PIM DataReader read/take operations return a sequence. However there is no similar operation on the DataWriter.

    This makes the API non-symmetric.

    In fact the new DDS C++ PSM added a write() operation that takes a forward iterator. Which now is only available in this PSM and not the others.

    This operation should be added to the PIM as it is a generic capability that should be available on all PSMs.

  • Reported: DDS 1.4 — Fri, 1 Jul 2016 01:12 GMT
  • Updated: Fri, 1 Jul 2016 01:12 GMT

Definition of BuiltinTopicKey_t

  • Key: DDS15-153
  • Legacy Issue Number: 10581
  • Status: open  
  • Source: MilSOFT ( Ertan Deniz)
  • Summary:

    The PSM mapping of BuiltinTopicKey_t is defined to be as:

    struct BuiltinTopicKey_t { 
        BUILTIN_TOPIC_KEY_TYPE_NATIVE value[3]; 
    }; 
    

    But the DDS Interoperability Wire Protocol (RTPS) specifies that GUID consists of 12 bytes GuidPrefix and 4 bytes EntityId.

    In order to map GUID and BuiltinTopicKey, we should define BuiltinTopicKey as either

    typedef octet BuiltinTopicKey[16];
    

    or else if we really wanted to preserve the definition as an array of longs

    struct BuiltinTopicKey_t { 
        BUILTIN_TOPIC_KEY_TYPE_NATIVE value[4]; 
    }; 
    

    But the latter could cause problems due to different endianess unless we also specified how to place the octets that arrive at the protocol level into the array of long.

  • Reported: DDS 1.2 — Tue, 9 Jan 2007 05:00 GMT
  • Updated: Tue, 24 May 2016 00:30 GMT

Legal characters and length of Topic Name

  • Key: DDS15-197
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The DDS specification states a Topic name is a string but it does not state what the legal characters are. It would therefore be possible to use "unprintable" characters which could create difficulties with printing and logginf messages.
    Because of this it is also possible for multiple vendors to put in place restrictions that could cause incompatibilities.

    For this reason it is desirable that the specification states with characters are legal within a Topic name.

    In addition RTPS version 2.2 defines TopicName as string<256> this should also be reflected in DDS.

  • Reported: DDS 1.4 — Tue, 17 May 2016 21:54 GMT
  • Updated: Tue, 17 May 2016 21:57 GMT

Clarification of resource management

  • Key: DDS15-183
  • Legacy Issue Number: 10357
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    I don't think that it is explicitly stated anywhere in this spec that each DataWriter and each DataReader maintains its own set of samples. Samples are not maintained by Publishers, Subscribers. It is implied in several places, e.g. the fact that RESOURCE_LIMITS applies to DataWriter and DataReader and not to Publisher and Subscriber. It took me a while to figure this out. It is possible for a Publisher to have more than one DataWriter with the same topic, and a Subscriber to have more than one DataReader with the same topic. The semantics of DataReader.take, for instance, are unclear unless it is understood that each DataReader has its own samples. Evidently a take operation on one DataReader does not disturb the samples of another DataReader with the same Publisher and Topic. Please clarify the specification in this regard. Figure 2-1 and accompanying text would be one place.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 17 May 2016 21:50 GMT

Clarification of create_multitopic behavior

  • Key: DDS15-182
  • Legacy Issue Number: 10358
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "The resulting type is specified by the type_name argument." What happens if the specified type is inconsistent with the subscription_expression?

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 17 May 2016 21:49 GMT

Typo on description of class TopicDescription

  • Key: DDS15-181
  • Legacy Issue Number: 10359
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    The class description for TopicDescription says "no attributes" but in fact two attributes are listed immediately below.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 17 May 2016 18:43 GMT

Clarify behavior of register_type operation

  • Key: DDS15-179
  • Legacy Issue Number: 10361
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "The application may pass nil as the value for the type_name. In this case the default typename as defined by the TypeSupport (i.e., the value returned by the get_type_name operation) will be used." What happens if register_type is given a type_name that differs from the result of get_type_name?

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 17 May 2016 18:42 GMT

Typo on descripton of "read" operation

  • Key: DDS15-176
  • Legacy Issue Number: 10364
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "The use of this variant allows for zero-copy access to the data and the application will need to “return the loan” to the DataWriter using the return_loan operation (see Section 2.1.2.5.3.20 )." Should be DataReader?

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 17 May 2016 18:41 GMT

Clarify behavior of "take" operation

  • Key: DDS15-175
  • Legacy Issue Number: 10365
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "The act of taking a sample removes it from the DataReader so it cannot be ‘read’ or ‘taken’ again." See my earlier comment. Apparently if there are other DataReaders for the same Topic and the same Subscriber, their samples are not disturbed. Assuming this is true, it should be stated.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 17 May 2016 18:40 GMT

Typo in description of "persistence" service reponsibility

  • Key: DDS15-173
  • Legacy Issue Number: 10367
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "The “persistence service” is the one responsible for implementing the DURABILITY kinds TRANSIENT and PERSISTENCE." You mean PERSISTENT

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 17 May 2016 18:37 GMT

Typo in Section: 2.1.3.14

  • Key: DDS15-172
  • Legacy Issue Number: 10368
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "In other words, the DataReader may miss some datasamples but it will never see the value of a data-object change from a newer value to an order value." You mean "older".

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Sat, 2 Apr 2016 20:38 GMT

Clarification of instance_state -- Section: 2.1.2.5.1.3

  • Key: DDS15-178
  • Legacy Issue Number: 10362
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "For each instance the middleware internally maintains an instance_state." Obviously this instance_state could be different for different DomainParticipants. Might it be different for two Subscribers of the same DomainParticipant? How about two DataReaders of the same Subscriber?

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Sat, 2 Apr 2016 20:37 GMT

Behavior of multiple calls to create_topic -- Section: 2.1.2.3.2

  • Key: DDS15-180
  • Legacy Issue Number: 10360
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "A Topic is identified by its name, which must be unique in the whole Domain." There is nothing in the description of create_topic that indicates that this constraint is enforced. Is it possible for multiple domain_participants to execute create_topic with the same name? What happens if they specify different types?

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Sat, 2 Apr 2016 20:36 GMT

Clarify RxO behavior for DURABILITY Qos

  • Key: DDS15-196
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    This issue was reported by email by Virginie Watine from THALES.

    Assume a DW is TRANSIENT and a DR is VOLATILE.
    According to the RxO policy attached to that QoS, they should match (all the other factors being OK). Is it correct?
    (at least that is what the spec says)

    But what are the first samples that are provided to the DR? I assume it receives only the ones that are produced after its creation (as opposed to a DR with TRANSIENT which receives also the ones that have been produced before its creation). Is it correct?
    (that point is not explained in the spec – or at least is not easy to find)

  • Reported: DDS 1.4 — Thu, 31 Mar 2016 18:04 GMT
  • Updated: Thu, 31 Mar 2016 18:07 GMT

Typo in section 2.2.2.5 Subscription Module

  • Key: DDS15-195
  • Status: open  
  • Source: Technical University of Madrid ( Jesús Rodríguez-Molina)
  • Summary:

    While this is a very minor issue, it is a good idea to mention it. In the line starting with "To ensure corerctness and portability" I guess it is meant "To ensure correctness and portability", thus having a typo in "corerctness". Am I right?

    Kind regards,

    Jesús Rodríguez-Molina

  • Reported: DDS 1.4 — Wed, 16 Mar 2016 11:36 GMT
  • Updated: Wed, 16 Mar 2016 18:58 GMT

[DDS] Data types permissible as topic key fields

  • Key: DDS15-30
  • Legacy Issue Number: 14089
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    The DDS 1.2 standard does not mention which IDL data types are permissible as
    key fields for topic data types.

    As the data types for keys, at least enumeration types and integral types
    (octet/short/long etc.) should be permissible.
    However, it would be desirable to also allow simple (non-array) typedefs
    of these types.

  • Reported: DDS 1.2 — Wed, 22 Jul 2009 04:00 GMT
  • Updated: Tue, 15 Mar 2016 16:05 GMT

Coherent updates with best efforts

  • Key: DDS15-194
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Clarify what happens if coherent updates involve best-effors writers. Would missing one sample cause the whole set to be discarded?

    Affects both TOPIC coherence and GROUP coherence if there are some best-efforts writers in the Publisher

  • Reported: DDS 1.4 — Tue, 15 Mar 2016 15:36 GMT
  • Updated: Tue, 15 Mar 2016 15:36 GMT

Invalid DURABILITY_SERVICE reference on the DataWriter

  • Key: DDS15-185
  • Legacy Issue Number: 9547
  • Status: open  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:
    In the QoS table (section 2.1.3. Supported QoS) the 'concerns' row illegally specifies the DataWriter for the DURABILITY_SERVICE QoS.

    Proposed Resolution:

    Proposed Revised Text:
    Section 2.1.3 Supported QoS, QoS Table:
    Entry for DURABILITY_SERVICE QoS, remove the word 'DataWriter' from the 'concerns' column.

  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Updated: Tue, 15 Mar 2016 15:17 GMT

DATAWRITER_QOS_USE_TOPIC_QOS and DATAREADER_QOS_USE_TOPIC_QOS

  • Key: DDS15-188
  • Legacy Issue Number: 19651
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 7.2.3 the defines DATAWRITER_QOS_USE_TOPIC_QOS
    and DATAREADER_QOS_USE_TOPIC_QOS do exist but they are not mentioned anywhere in the spec. Not sure if they should be removed, or documented

  • Reported: DDS 1.2 — Fri, 31 Oct 2014 04:00 GMT
  • Updated: Tue, 15 Mar 2016 15:02 GMT

Force KEEP_ALL to be RELIABLE Section: 2.1.3.18

  • Key: DDS15-171
  • Legacy Issue Number: 10369
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "If the kind is set to KEEP_ALL, then the Service will attempt to maintain and deliver all the values of the instance to existing subscribers. The resources that the Service can use to keep this history are limited by the settings of the RESOURCE_LIMITS QoS. If the limit is reached, then the behavior of the Service will depend on the RELIABILITY QoS. If the reliability kind is BEST_EFFORT, then the old values will be discarded." This violates the ordinary English meaning of KEEP_ALL. Can't the same effect be achieved by specifying KEEP_LAST with history_depth=max_samples_per_instance? If so, then KEEP_ALL should not be allowed for RELIABILITY=BEST_EFFORT.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 15 Mar 2016 14:41 GMT

The DDS Specification should define legal DDS Topic Types

  • Key: DDS15-20
  • Legacy Issue Number: 19141
  • Status: open  
  • Source: PrismTech ( Angelo Corsaro)
  • Summary:

    The DDS v1.2 specification does not explicitly define the subset of IDL that can be used to express Topic Types. From the specification, it can be inferred – and all vendor have done so – that a topic type is defined by means of a struct and that the IDL types that cannot be used for the attributes of this struct are Value-Types, Any Types and Object References.

    The DDS v1.2 should explicitly state this. Notice the the problem is not solved by the X-Types specification as that introduces a set of types, such as Maps, Optional types, etc. that are not supported by DDS v1.2 implementations.

    This is really a critical matter which is trivial to solve. Just state what is implicitly assumed and should be fixed ASAP.

  • Reported: DDS 1.4 — Thu, 12 Dec 2013 05:00 GMT
  • Updated: Tue, 15 Mar 2016 14:32 GMT

Deprecated usage of IDL in the DDS spec

  • Key: DDS15-33
  • Legacy Issue Number: 12539
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    The CORBA specification (08-01-04) in section 7.11.6 deprecates the use of anonymous types, for example the type of the struct field "seq" below:
    struct Foo

    { sequence<octet> seq; }

    ;

    The DDS DCPS IDL uses these in multiple places (the first is DDS::UserDataQosPolicy). These should be replaced with non-deprecated usage such as:
    typedef sequence<octet> OctetSeq;
    struct Foo

    { OctetSeq seq; }

    ;

    This will also increase internal consistency of the DDS spec, since it already uses a DDS::StringSeq typedef in the PartitionQosPolicy struct.

    Furthermore, if the element type of the sequence is a Basic Type or a String Type, the CORBA module already provides these typedefs, so it would be preferable to use them. The example above becomes:
    struct Foo

    { CORBA::OctetSeq seq; }

    ;

  • Reported: DDS 1.2 — Fri, 20 Jun 2008 04:00 GMT
  • Updated: Tue, 15 Mar 2016 14:24 GMT

Cancel coherent update

  • Key: DDS15-45
  • Legacy Issue Number: 10812
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    It is possible that a transaction needs to be canceled, for example because one of the participating writers gets blocked and finally stops while returning a timeout. This might lead to the situation in which you want to cancel all preceding writes as well.

    Solution:
    To be able to cancel such a transaction, we propose to add an additional operation like e.g. cancel_coherent_changes would then remove all samples that have already been written since the last begin_coherent_changes.

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Tue, 15 Mar 2016 14:23 GMT

Specify Publishers with PRESENTATION access_scope GROUP should use same order for DataWriters

  • Key: DDS15-190
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    When PRESENTATION access_scope is GROUP samples need to e ordered across DataWriters. This is very hard/impossible if some writers use source_timestamp and others reception timestamp order

    Propose that this is not allowed. If PRESENTATION access_scope is GROUP then all writers must have same ORDER. E.g. as writers are created if one is not consistent it should give an error

  • Reported: DDS 1.4 — Tue, 15 Mar 2016 14:11 GMT
  • Updated: Tue, 15 Mar 2016 14:11 GMT

The get_sample_lost method seems to be part of the Subscriber class

  • Key: DDS15-17
  • Legacy Issue Number: 10980
  • Status: open  
  • Source: KDA ( Ingvill Grefstad)
  • Summary:

    Page 2-70, The get_sample_lost method seems to be part of the Subscriber class. However, according to the UML-diagram page 2-62 and the idl-listing page 2-166 and , the get_sample_lost method should belong to the DataReader class - not the Subscriber.

  • Reported: DDS 1.1 — Wed, 2 May 2007 04:00 GMT
  • Updated: Tue, 15 Mar 2016 13:37 GMT

Introduce new typedef

  • Key: DDS15-16
  • Legacy Issue Number: 13950
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    UserDataQosPolicy, TopicDataQosPolicy, and GroupDataQosPolicy use an anonymous sequence, this is deprecated in IDL. A new typedef for this should be introduced

  • Reported: DDS 1.2 — Mon, 8 Jun 2009 04:00 GMT
  • Updated: Tue, 15 Mar 2016 13:34 GMT

: #define HANDLE_TYPE_NATIVE long typedef HANDLE_TYPE_NATIVE InstanceHandle_t;

  • Key: DDS15-14
  • Legacy Issue Number: 14165
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The DDS spec defines: #define HANDLE_TYPE_NATIVE long typedef HANDLE_TYPE_NATIVE InstanceHandle_t; We see that some vendors use long, other a struct containing an octet array. This is causing problems when integrating DDS into CCM. A CORBA::Long is passed by value, a struct is passed as const &. At least the way the InstanceHandle_t is passed to methods and returned should be the same. We propose to change this type to: struct NativeInstanceHandle_t

    { // Vendor defined }

    ; typedef NativeInstanceHandle_t InstanceHandle_t; That way we always have a struct passed as const&.

  • Reported: DDS 1.2 — Thu, 30 Jul 2009 04:00 GMT
  • Updated: Tue, 15 Mar 2016 13:30 GMT

DDS Entities should have a name

  • Key: DDS15-28
  • Legacy Issue Number: 16029
  • Status: open  
  • Source: PrismTech ( Angelo Corsaro)
  • Summary:

    DDS Entities (DomainParticipant, Publisher, Subscriber, DataReader and DataWriter) have associated GUID but the current API does not provide any way of associating them a symbolic name, such as "com.acme.mycoolapp.DomainParticipantFoo"

    The DDS PIM should be extended to support the explicit setting of entity names. When not set explicitly, vendors should be free to pick meaningful names.

  • Reported: DDS 1.2 — Wed, 16 Feb 2011 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

DDS typos and omissions

  • Key: DDS15-37
  • Legacy Issue Number: 12212
  • Status: open  
  • Source: Anonymous
  • Summary:

    1. Section 7.1.4.4 Conditions and Wait-sets - Two paragraphs above figure 7.19 is "The blocking behavior of the WaitSet is illustrated in Figure 7.18" I think this is meant to reference figure 7.19 instead.

    2. Section 7.1.6.2.2 Notifications via Conditions and Wait-Sets - starts out with "The first part of Figure 7.21" I think it should be figure 7.22

    3. In section 7.2.3 DCPS PSM : IDL on pages 152 - 153 are definitions of all the IDs and names of the QOS Policies with the exception that "TRANSPORTPRIORITY" has an ID definition but is missing a name definition. 4. Section 7.1.2.2.2.7 set_qos
    This operation sets the value of the DomainParticipantFactory QoS policies. These policies control the behavior of the
    object a factory for entities.

  • Reported: DDS 1.2 — Mon, 4 Feb 2008 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Get entity enabled state

  • Key: DDS15-44
  • Legacy Issue Number: 10813
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    It should be possible to obtain the "enabled" state of an Entity

    Solution:
    We propose to add a boolean operation to the Entity called something like is_enabled().

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Semantics instance liveliness and ownership unclear

  • Key: DDS15-49
  • Legacy Issue Number: 10808
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    From the OMG DDS specification the semantic of the liveliness of a reader instance is not clear, when it is exclusively owned by a writer. The LivelinessChangedStatus of the reader indicates how many active and inactive writers communicate with the reader. In case of exclusive ownership it is unclear whether only the reader sees the strongest writer as an active writer, or when it must see all available writers, since the reader will only receive samples from the strongest writer.

    Solution:
    Do we need to clarify this?

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Add name attribute to Entity

  • Key: DDS15-50
  • Legacy Issue Number: 10807
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    For system management it is very useful that Entities can be identified by a logical application defined name. This attribute should ideal be set via the factory create call but if changing API's is not desired it can also be set via a QoS policy. This attribute should also be supported by the built-in Topics

    Solution:
    Introduction of a new Properties QoS that can be used for a name, but also for other things. The new QoS would contain a sequence of "properties" where each property is a pair of strings:
    (property_name, property_value)
    This Properties QoS can be used very much the same as the USER_DATA, but because each property is named, multiple things can be stored without conflicting with each other. This also provides an extensibility mechanism for the DDS spec. We can reserve the property-names with the prefix "DDS." To indicate "built-in" properties that should not be used by applications.
    We can use this mechanism with the built-in property name "DDS.EntityName" to implement the name attribute.

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

create_contentfilteredtopic Method Prototype and Description Out

  • Key: DDS15-184
  • Legacy Issue Number: 9964
  • Status: open  
  • Source: Anonymous
  • Summary:

    I was looking at the DDS specification and saw that the name of the first parameter for DomainParticipant's create_contentfilteredtopic method is "name" in the table of methods (section 2.1.2.2.1) and it is "topic_name" in the method description (section 2.1.2.2.1.7). I assume the name should be consistent.

  • Reported: DDS 1.2 — Tue, 25 Jul 2006 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

ContentFilteredTopics should be removed. Filtering belongs to DataReaders

  • Key: DDS15-2
  • Legacy Issue Number: 18311
  • Status: open  
  • Source: PrismTech ( Angelo Corsaro)
  • Summary:

    The DDS v2.1 introduces the concept of a ContentFilteredTopic in order to express filtering on a DataReder. The ContentFilteredTopic is a local entity that is not distributed via discovery. In addition content filters are already distributed as part of DataReader discovery.

    As such it would be cleaner and more sensible to remove the ContentFilteredTopic and allow to express the filter directly through either DataReader QoS or as a Filter parameter (see DDS-PSM-Cxx for inspiration).

  • Reported: DDS 1.2 — Wed, 12 Dec 2012 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Allow for more optimized list returned by get_datareaders()

  • Key: DDS15-22
  • Legacy Issue Number: 17364
  • Status: open  
  • Source: Real-Time Innovations ( Fernando Sanchez)
  • Summary:

    Found by: Fernando Crespo
    Severity:

    Problem:
    OMG DDS spec (section 7.1.2.5.2.10) states that the sequence returned by
    get_datareaders() will contain list containing each DataReader one or more times.
    For example, if multiple consecutive samples in a group belong to the same DataReader
    the DataReader is repeated in the list returned by get_datareaders().
    Having to process each element, even when they belong to the same DataReader is
    less performant.

    Proposed Resolution:
    Modify the specification to return one DataReader element, instead of a list where
    a DataReader is repeated multiple times, when multiple subsequent samples belong to
    the same DataReader. This allows for more optimized processing where the user calls
    read/take until the return code is NO_DATA.

  • Reported: DDS 1.2 — Tue, 8 May 2012 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

All IDL should use local interfaces

  • Key: DDS15-29
  • Legacy Issue Number: 15945
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    DDS uses IDL and defines its interface as regular interfaces, but these should all be local interfaces

  • Reported: DDS 1.4 — Thu, 13 Jan 2011 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

subset of OMG IDL

  • Key: DDS15-186
  • Legacy Issue Number: 8892
  • Status: open  
  • Source: nswc.navy.mil ( Traci McDonald)
  • Summary:

    In the DDS specification version 05-03-09, page 2-1 specifies that the PSM is for the OMG IDL platform. In section 2.2.1 (page 2-193), more detail is given as to what this PSM looks like. One area I don't see covered is the subset of OMG IDL that the DDS specification supports from a user's perspective. When a user defines an IDL file, what data types should and shouldn't be used? It looks as though valuetypes are not supported, but is it possible to explicitly specify what OMG IDL types are supported by implementations of the DDS specification?

  • Reported: DDS 1.1 — Thu, 16 Jun 2005 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Write with handle_nil underspecified

  • Key: DDS15-3
  • Legacy Issue Number: 17413
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For write the DDS spec says:

    The special value HANDLE_NIL can be used for the parameter handle. This indicates that the identity of the instance
    should be automatically deduced from the instance_data (by means of the key).

    The case which is not specified is the case where the handle is HANDLE_NUL, but they key we use hasn't been registered with dds yet, will DDS than return an error, or automatically register a new instance?

  • Reported: DDS 1.2 — Fri, 8 Jun 2012 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

DDS specification should be more precise on NATIVE defines

  • Key: DDS15-9
  • Legacy Issue Number: 15834
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    DDS leaves domainid, handle, and topic key to the dds vendor, each can define their own type for these. The specification has defines for them, but the default is long. If now a vendor uses for example a struct for the InstanceHandle_t, this leads to challenges when writing portable C++ code because the argument passing is different between a long (as value) or a fixed struct (const &). To my idea the dds specification should be more precise on the type, maybe fixed struct to achieve more portability of users code

  • Reported: DDS 1.2 — Wed, 17 Nov 2010 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Add DDS::STATUS_MASK_NONE

  • Key: DDS15-10
  • Legacy Issue Number: 15041
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We want to propose to extend the DDS status masks with DDS::STATUS_MASK_NONE which is defined as 0. This is cleaner for application code.

  • Reported: DDS 1.2 — Mon, 8 Feb 2010 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

For ContentFilteredTopic::get_expression_parameters the argument name is not given in the spec

  • Key: DDS15-15
  • Legacy Issue Number: 13951
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For ContentFilteredTopic::get_expression_parameters the argument name is not given in the spec, this way the IDL isn't complete and compilable Also MultiTopic::get_expression_parameters has the same issue Also DataWriter::get_liveliness_lost_status has this issue

  • Reported: DDS 1.2 — Mon, 8 Jun 2009 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

History and Reliability should be orthogonally independent concerns

  • Key: DDS15-25
  • Legacy Issue Number: 17284
  • Status: open  
  • Source: PrismTech ( Angelo Corsaro)
  • Summary:

    The current DDSv1.2 specification provides a slightly different semantics for the history on the writer side and on the reader.

    In addition, the DDS v1.2 specification allows to use the data-writer history as the "reliability-send-queue" – this is combined with the fact that History is (correctly) not an RxO policy leads to a serious bug in the spec (luckily not all DDS implementations follow this path) . Let's try to understand why.

    Firs, it is important to comprehend that unless a data writer uses KeepAll history, reliable data delivery is not guaranteed to matching data readers. This can't be guaranteed even when using Reliable communication (obviously ignoring data-writer crashes for the time being).

    Essentially, under this scheme a DataWriter is allowed send/re-send only what is in its history cache. If a sample is out of history a DataWriter won't do anything, thus leading to potential inconsistencies in case some reader has lost the message.

    Things get very messy when a DataReader with KeepAll History is matching a DataWriter that does uses KeepLast. In this case, the poor DataReader which might legitimally expect to have on his history all the samples written by the writers – without holes – might finds him-/her-self surprised by the fact that some samples might be missing.

  • Reported: DDS 1.4 — Thu, 29 Mar 2012 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

No specific package definition for the entities of the model in case of JAVA language binding

  • Key: DDS15-32
  • Legacy Issue Number: 13448
  • Status: open  
  • Source: Selex ES ( Dario Di Crescenzo)
  • Summary:

    The DDS specification document does not prescribes a specific package definition for the entities of the model in case of JAVA language binding; in the IDL only a "DDS" module is defined which does not result in a strictly specified package structure (it might only imply that the entities belong to the DDS package/namespace). It would be useful to have a precise statement indicating at least for the JAVA binding the packages to which the DDS Entities must belong in order to have all implementations using the same packages for the same Entities (e.g org.omg.dds.infrastructure, org.omg.dds.domain, etc..)

  • Reported: DDS 1.4 — Fri, 6 Feb 2009 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

DDS DCPS Issue: PRESENTATION=GROUP and QoS

  • Key: DDS15-43
  • Legacy Issue Number: 10993
  • Status: open  
  • Source: OCI ( Don Busch)
  • Summary:

    Section 7.l.3.6 of the DCPS spec should indicate what happens under the PRESENTATION=GROUP policy when different DataWriters in the group have different QoS settings. Whose settings are followed by the group? The most stringent? The least stringent? Group membership is dynamic, so the group members are not knows until each write() happens

  • Reported: DDS 1.2 — Wed, 9 May 2007 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Invalid DURABILITY_SERVICE reference on the DataWriter

  • Key: DDS15-51
  • Legacy Issue Number: 10806
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    In the QoS table (Section 2.1.3 Supported QoS) the 'concern' row illegally specifies the DataWriter for the DURABILITY_SERVICE QoS.

    Solution:
    Section 2.1.3 Supported QoS, QoS Table:
    Entry for DURABILITY_SERVICE QoS, remove the word 'DataWriter' from the 'Concerns' column.
    If we do this it would need to be removed from the BuiltinPublicationData.

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Section: 2.1.2.5.3

  • Key: DDS15-177
  • Legacy Issue Number: 10363
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: DataReader.read operation Why are sample_states, view_states, and instance_states provided as separate parameters? Aren't they contained in sample_infos? More explanation required.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

TypeSupport::get_type_name should be precisely specified

  • Key: DDS15-1
  • Legacy Issue Number: 18468
  • Status: open  
  • Source: PrismTech ( Angelo Corsaro)
  • Summary:

    The description of the TypeSupport::get_type_name operation currently states:

    "This operation returns the default name for the data-type represented by the TypeSupport."

    The problem is that the default name for the data-type is not specified anywhere. One logical choice would be the fully qualified type as per the IDL syntax. As an example org::omg::dds::demo::ShapeType.

    If the specification does not clearly mandate the representation for the topic type interoperability may be hindered unless users explicitly override topic types.

    This is very unfortunate and a critical issue that should be addressed ASAP.

  • Reported: DDS 1.2 — Thu, 21 Feb 2013 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

InstanceHandle_t/Domain ID

  • Key: DDS15-5
  • Legacy Issue Number: 16266
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    InstanceHandle_t is underspecified, The IDL PSM that should use a struct, so that argument passing is the same for all values

    In the IDL PSM, I see that copying and comparing instance handles is underspecified.

    The same issue applies to domain IDs, actually, which also have unspecified contents in that PSM.)

  • Reported: DDS 1.2 — Thu, 26 May 2011 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

DDS defines Time_t with seconds as long, this is 32bit. This will give an issue after 2038

  • Key: DDS15-13
  • Legacy Issue Number: 14166
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    DDS defines Time_t with seconds as long, this is 32bit. This will give an issue after 2038, almost all operating systems are now defining time as 64bit, shouldn't DDS do the same?

  • Reported: DDS 1.2 — Thu, 30 Jul 2009 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Wrong definition of GROUPDATA_QOS_POLICY_NAME constant in IDL

  • Key: DDS15-21
  • Legacy Issue Number: 18320
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    GROUPDATA_QOS_POLICY_NAME is given as "TransportPriority", and the corresponding *_POLICY_NAME from TRANSPORTPRIOIRTY is missing.

    Index: dds/DdsDcpsInfrastructure.idl
    ===================================================================
    — dds/DdsDcpsInfrastructure.idl
    +++ dds/DdsDcpsInfrastructure.idl
    @@ -327,7 +327,8 @@
    const string WRITERDATALIFECYCLE_QOS_POLICY_NAME = "WriterDataLifecycle";
    const string READERDATALIFECYCLE_QOS_POLICY_NAME = "ReaderDataLifecycle";
    const string TOPICDATA_QOS_POLICY_NAME = "TopicData";

    • const string GROUPDATA_QOS_POLICY_NAME = "TransportPriority";
      + const string GROUPDATA_QOS_POLICY_NAME = "GroupData";
      + const string TRANSPORTPRIORITY_QOS_POLICY_NAME = "TransportPriority";
      const string LIFESPAN_QOS_POLICY_NAME = "Lifespan";
      const string DURABILITYSERVICE_POLICY_NAME = "DurabilityService";
  • Reported: DDS 1.4 — Mon, 17 Dec 2012 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

'synchrobnous' and 'asynchronous' switched

  • Key: DDS15-34
  • Legacy Issue Number: 12465
  • Status: open  
  • Source: Anonymous
  • Summary:

    While reading the DDS specification, 'Data Distribution Service for Real-time Systems Version 1.2 OMG Available Specification formal/07-01-01', I found that the 'synchrobnous' and 'asynchronous' was switched as highlighted in red in the below paragraph in the spec.

    <para #4, page 11>
    On the subscriber’s side however, there are more choices: relevant information may arrive when the application is busy doing something else or when the application is just waiting for that information. Therefore, depending on the way the application is designed, asynchronous notifications or synchronous access may be more appropriate. Both interaction modes are allowed, a Listener is used to provide a callback for synchronous access and a WaitSet associated with one or several Condition objects provides asynchronous data access.

  • Reported: DDS 1.2 — Wed, 14 May 2008 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

DURABILITYSERVICE_POLICY_NAME

  • Key: DDS15-36
  • Legacy Issue Number: 12276
  • Status: open  
  • Source: lmco.com ( Abdullah Sowayan)
  • Summary:

    noticed an inconsistency while I was reading the DDS spec (version
    1.2) last night. My question relates to the following quality of
    service policy:
    DURABILITYSERVICE_POLICY_NAME

    The pattern in all QoS names is:

    *_QOS_POLICY_NAME, except for the DURABILITYSERVICE

    The pattern in all QoS IDs is:

    *_QOS_POLICY_ID

    The DURABILITYSERVICE does adhere to the pattern/convention for Qos IDs:

    DURABILITYSERVICE_QOS_POLICY_ID

    But the does NOT adhere to the pattern/convention for Qos names. So, is
    there a typo in DURABILITYSERVICE_POLICY_NAME, i.e., should it be
    DURABILITYSERVICE_QOS_POLICY_NAME, or is the lacking of QOS
    intentional?

  • Reported: DDS 1.2 — Thu, 13 Mar 2008 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Section: 2.1.3

  • Key: DDS15-174
  • Legacy Issue Number: 10366
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "And three integers: history_depth, max_samples, max_instances, max_samples_ per_instance" There are four integers here.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Spec lacks definition regarding uniqueness of InstanceHandle_t

  • Key: DDS15-4
  • Legacy Issue Number: 17412
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec defines the following:
    7.1.2.1.1.8 get_instance_handle
    This operation returns the InstanceHandle_t that represents the Entity.

    But it doesn't specify in how far this InstanceHandle_t has to be unique. When the user receives an InstanceHandle_t, is it than unique within the same domain participant, within the process or within the complete dds domain? If it is for example just unique within one domain participant, we can't use it for example as key in a map which could contain entities from multiple domain participants

  • Reported: DDS 1.2 — Fri, 8 Jun 2012 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

get_type_name, class or object method

  • Key: DDS15-6
  • Legacy Issue Number: 16262
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    It seems that DDS vendors are implementing get_type_name of the TypeSupport interfaces differently. Some do it as static class method in C++, some as a regular method. The spec uses regular IDL, which gives the idea that it is a regular method needed a concrete TypeSupport instance, but I doubt whether that is intended

  • Reported: DDS 1.2 — Tue, 24 May 2011 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

behaviour of redefining multiple times the same topic with different QoS not clearly specified

  • Key: DDS15-27
  • Legacy Issue Number: 16098
  • Status: open  
  • Source: PrismTech ( Angelo Corsaro)
  • Summary:

    The DDS v1.2 specification does not clearly specify the behaviour of redefining multiple times the same topic with different QoS. As a Topic represents a global assertion, having different applications associating different QoS with the same topic should be flagged as an error.

  • Reported: DDS 1.2 — Fri, 25 Mar 2011 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

DataReader semantics for historical data are insufficient

  • Key: DDS15-52
  • Legacy Issue Number: 10805
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    The current specification provides no solution for the following two use-cases:
    · A Volatile DataReader can receive data from a Transient or persistent DataWriter so it may also be interested in historical data. However a DataReader cannot receive historical data. Just making the DataReader Transient does not solve the problem because the DataReader may also be interested in volatile data.
    · A Transient or Persistent DataReader may not be interested in historical data, there is no way to avoid receiving historical data. A DataReader may be e.g. Transient to avoid receiving data from volatile DataWriters, in addition there may be no interest in historical data.

    Solution:
    Separate the control of receiving historical data from the DataReaders durability interest. The DataReaders Durability interest will specify from which DataWriter it will accept data. A separate call will control (ask for) the retrieval of historical data.
    Add the following method
    ReturnCode_t get_historical_data(Duration_t max_wait)
    And Transient and Persistent DataReaders should not automatically receive historical data. A consequence is that this invalidates the method
    ReturnCode_t wait_for_historical_data(Duration_t max_wait).

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

DDS should require to annotate IDL to indicate which IDL types are used for dds

  • Key: DDS15-8
  • Legacy Issue Number: 15835
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In a CCM/DDS4CCM based system not all IDL defined types are intended to be used with dds. At this moment there is not a standardized way to indicate that a type should be usable with DDS. If I now have a large file with a lot of types, DDS just assumes that everything should be transmittable through DDS and generates a lot of code. Just like can indicate the keys of a struct, I think DDS should define a standardized way to annotate the idl so that just some types in a file are handled by the dds tooling

  • Reported: DDS 1.2 — Wed, 17 Nov 2010 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Add new mask which will let DDS callback on the listener to gets its mask

  • Key: DDS15-12
  • Legacy Issue Number: 14814
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    DDS has several methods to create entities and pass a listener. With the listener than a mask has to be passed. It would be much cleaner for some C++ systems when we can pass a special mask which means that DDS will callback on the listener to gets its mask, this reduces the application code and could lead to a cleaner user code architecture

  • Reported: DDS 1.2 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Default built-in ReaderDataLifecycle values

  • Key: DDS15-46
  • Legacy Issue Number: 10811
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    QoS settings of buildin Readers: according to section 2.1.5 builtin Readers should have its ReaderDataLifecycles delays set to infinite, meaning that builtin topics that are disposed and/or unregistered will never be removed from the system unless explicitly 'taken'. If an application never bothers to look at the builtin readers, they will never clean up resources and these readers will use up more and more memory if entities keep on joining and leaving the network.

    Solution:
    We propose to give the builtin-readers a finite duration for both auto_purge variables (for example something like 5 minutes).

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Inconsistent lookup semantics

  • Key: DDS15-47
  • Legacy Issue Number: 10810
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    There is inconsistency in the spec: on page 2-24 there is a list of operations that is allowed when the DomainParticipant is in the disabled state. This list does not include any lookup operations. However, on page 2-14 there is also a list of operations which may be invoked when Entity has not yet been enabled, and here the 'lookup' operations are mentioned. So the questions are whether the DomainParticipant should be allowed to perform "find_topic" and "lookup_topicdescription" operations when it is in disabled state.

    Solution:
    Our proposal is that find_topic should not be allowed in this case, but lookup_topicdescription should be allowed. Also all delete operations including the delete_contained_entities should be allowed

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Add several with_profile methods

  • Key: DDS15-7
  • Legacy Issue Number: 15904
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    DDS4CCM adds support for qos xml files. There is no api in dds to create a dp/sub/pub/rd/wr with a qos given from the xml file. We propose to add the following methods to the DDS IDL to create dds entities with a qos xml profile.

    local interface DomainParticipant : Entity

    { Publisher create_publisher_with_profile( in string library_name, in string profile_name, in PublisherListener a_listener, in StatusMask mask); Subscriber create_subscriber_with_profile( in string library_name, in string profile_name, in SubscriberListener a_listener, in StatusMask mask); Topic create_topic_with_profile( in string topic_name, in string type_name, in string library_name, in string profile_name, in TopicListener a_listener, in StatusMask mask); }

    ;

    local interface DomainParticipantFactory

    { DomainParticipant create_participant_with_profile( in DomainId_t domain_id, in string library_name, in string profile_name, in DomainParticipantListener a_listener, in StatusMask mask); ReturnCode_t set_default_participant_qos_with_profile( in string library_name, in string profile_name); }

    ;

    local interface Publisher : Entity

    { DataWriter create_datawriter_with_profile( in Topic a_topic, in string library_name, in string probile_name, in DataWriterListener a_listener, in StatusMask mask); }

    ;

    local interface Subscriber : Entity

    { DataReader create_datareader_with_profile( in TopicDescription a_topic, in string library_name, in string profile_name, in DataReaderListener a_listener, in StatusMask mask); }

    ;

  • Reported: DDS 1.2 — Tue, 21 Dec 2010 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Extend Topic with method to retrieve key fields

  • Key: DDS15-11
  • Legacy Issue Number: 14829
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For template meta programming as we are doing for the dds4ccm spec, it is needed to know at runtime time of the user program whether a topic has a key or not, because behaviour is dependent on that. we propose to add methods to the Topic to get its key fields

  • Reported: DDS 1.2 — Wed, 2 Dec 2009 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

When using GROUP access scope presentation QoS, allow for read/take outside of begin_access and end_access block

  • Key: DDS15-23
  • Legacy Issue Number: 17363
  • Status: open  
  • Source: Real-Time Innovations ( Fernando Sanchez)
  • Summary:

    Found by: Fernando Crespo
    Severity:

    Problem: The DDS specification (section 7.1.2.5.2.8)
    does not allow access to the DDS cache when the
    application wants to access data, but does not
    care about the order across Data Writers.

    Proposed Resolution:
    When using GROUP access scope, allow both
    access patterns and do not return PRECONDITION_NOT_MET
    error code when called read, take, etc. without first
    called begin_access.

    Note: This also allows portability for applications which
    do not care about the order across topics.

  • Reported: DDS 1.2 — Tue, 8 May 2012 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

The compatibility rules for the Presentation QoS are too strict

  • Key: DDS15-24
  • Legacy Issue Number: 17362
  • Status: open  
  • Source: Real-Time Innovations ( Fernando Sanchez)
  • Summary:

    The compatibility rules for the Presentation QosPolicy,
    specified in section 7.1.3.6 of the DDS Specification
    prevent a subscriber configured using GROUP
    access scope from simultaneously matching a
    publisher configured using GROUP access scope
    and a publisher configured using TOPIC or
    INSTANCE access scope.

    Proposed Resolution:
    The addition of a new boolean field
    called "use_highest_offered_access_scope" to
    Presentation QosPolicy.

    This boolean is not propagated as part of the
    discovery information and remains local to the
    subscriber.
    Users configure the subscriber to the minimum
    accepted access scope. When the boolean field
    is set to true, the subscriber will provide the
    access_scope offered by the publisher as opposed to
    its own access_scope value.

    For example: a subscriber wanted to provide GROUP
    access scope when matched with a GROUP
    order publisher and with a publisher providing
    INSTANCE access scope, will use INSTANCE access
    scope and set the user_highest_offered_access_scope
    boolean to true.

  • Reported: DDS 1.2 — Tue, 8 May 2012 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Mapping of OMG IDL to C++ for DDS

  • Key: DDS15-31
  • Legacy Issue Number: 13839
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    The mapping of user written IDL to C++ is not described in the version 1.2 of
    the DDS standard.

    Is it expected that DDS use the existing CORBA C++ mapping for data types?
    If so then the standard should state this requirement.

    On the other hand, the CORBA IDL to C++ mapping is fairly old.
    The new DDS PSM for C++ would suggest a more modern mapping.

    For example, for bounded strings and bounded sequences, C++ classes inspired
    by the Standard Template Library (STL) could be used.
    These classes need not necessarily break the DCPS compatibility with the C
    language mentioned in 8.2.1.1. (Use fixed buffer, avoid virtual methods.)
    It is not clear whether unbounded data types need be supported, see issues
    8892 and 12360.

    In case a new mapping is defined which is independent of the CORBA C++
    mapping, there is a problem to address:
    Bridge applications which use both CORBA and DDS would need to translate a
    single IDL file twice, once for CORBA and again for DDS. Then there is an
    overlap in the generated names.
    This problem could be solved by encapsulating all C++ code generated for DDS
    from user IDL in an extra namespace.

  • Reported: DDS 1.2 — Fri, 27 Mar 2009 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Specify the allowed IDL Types within DDS Topic structs

  • Key: DDS15-35
  • Legacy Issue Number: 12360
  • Status: open  
  • Source: Naval Surface Warfare Center ( Paul Werme)
  • Summary:

    The DDS Spec (as of v1.2) does not specify the set of IDL types that are allowed in a DDS Topic struct. This should be defined and made normative instead of being left as an implementation detail.

    Discussion:

    Because the set of IDL types allowed in a DDS Topic struct is not defined, implementors are at liberty to decide what set of IDL types to support. Concerns about the impact of the lack of standardization in this area have been raised by the computing infrastructure teams on major Navy programs on several occasions particularly in regards to potential impact on code portability across DDS implementations and interoperability between DDS implementations.

    In reviewing the DDS C++ Native Language Mapping RFP, we commented that the RFP provided an opportunity to insert a requirement to define the allowed C++ types within a DDS Topic struct which would indirectly result in defining the set of allowed DDS IDL types due to the RFP requirement for the C++ mapping to be consistent with the IDL mapping. This suggestion was rejected because it was viewed that the correct forum and mechanism for resolving this issue was the DDS RTF. We were requested to submit this as an issue to the RTF since the RTF could probably resolve this issue within the next 6 months.

  • Reported: DDS 1.2 — Mon, 31 Mar 2008 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Missing TypeSupport operations

  • Key: DDS15-48
  • Legacy Issue Number: 10809
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    In IDL, the operations on the TypeSupport interface are commented out: all operations are defined in its specialized sub-classes. That is strange, since all TypeSupport operations have a signature that is completely independent of this specific type.

    Solution:
    We propose to promote all these operations to the TypeSupport class itself, and thus to uncomment these operations in the TypeSupport interface.

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Durability Implementation Description does not consider the role of partitions

  • Key: DDS15-187
  • Legacy Issue Number: 19649
  • Status: open  
  • Source: PrismTech ( Angelo Corsaro)
  • Summary:

    The third paragraph of the DURABILITY section (2.1.3.4) describes the semantics that has to be provided by a durability service for TRANSIENT and PERSISTENT topics. Specifically, it states that given a Topic T with DURABILITY QoS set to TRANSIENT or PERSISTENT then the "built-in fictitious" DataReader and DataWriter used by the Durability Service to receive/distribute data have to be created with the same QoS T. Yet, nothing is said with respect to the role of the PARTITION QoS. Section 2.1.3.13 clearly states that:

    "For a DataReader to see the changes made to an instance by a DataWriter, not only the Topic must match, but also they must share a common partition."

    Thus based on the current specification the Durability Service DataReader and DataWriter would only match the applications DataReader and DataWriter that are in the default partition.

  • Reported: DDS 1.4 — Wed, 29 Oct 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT