Data Distribution Service Avatar
  1. OMG Specification

Data Distribution Service — Open Issues

  • Acronym: DDS
  • Issues Count: 51
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
DDS15-256 Define InstanceHandle_t and DomainId_t portably DDS 1.4 open
DDS15-247 Names of listener operations are incorrect in UML diagrams DDS 1.4 open
DDS15-240 The start time of type Time_t is not defined DDS 1.4 open
DDS15-246 Collection of longs misrepresented in 2.2.1.1 MyClass DDS 1.4 open
DDS15-249 Consider replacing @Choice annotation with XTYPES 1.2 unions DDS 1.4 open
DDS15-251 Wrong name for DataRepresentationQosPolicy field DDS 1.4 open
DDS15-195 Typo in section 2.2.2.5 Subscription Module DDS 1.4 open
DDS15-20 The DDS Specification should define legal DDS Topic Types DDS 1.4 open
DDS15-235 DURABILITY history depth should be de-coupled from the KEEP_LAST history depth used for reliability DDS 1.4 open
DDS15-21 Wrong definition of GROUPDATA_QOS_POLICY_NAME constant in IDL DDS 1.4 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-309 Extend SampleInfo with sequenceNumber and reception_timestamp DDS 1.4 open
DDS15-197 Legal characters and length of Topic Name DDS 1.4 open
DDS15-26 Missing APIs for (read|take)_instance_w_condition DDS 1.4 open
DDS15-303 PARTITION PolicyQos should be in DataReader/DataWriter DDS 1.4 open
DDS15-194 Coherent updates with best efforts DDS 1.4 open
DDS15-248 Deprecate Basic Service Mapping DDS 1.4 open
DDS15-250 Align with XTYPES 1.3 and IDL 4.2 DDS 1.4 open
DDS15-266 Organize definitions of Time_t, Duration_t and other common types in the PIM DDS 1.4 open
DDS15-258 Add a DomainTag to the PSM DDS 1.4 open
DDS15-255 What can be done with a disabled Topic? DDS 1.4 open
DDS15-254 Specify the behavior of instance state machine in case of a disconnect-reconnect scenario DDS 1.4 open
DDS15-253 Consider adding some of the concepts in the new PSMs to the PIM DDS 1.4 open
DDS15-252 Clarify definition of counts in Plain Communication Status DDS 1.4 open
DDS15-245 Clarify the PartitionQosPolicy DDS 1.4 open
DDS15-244 Communication Status changes for multiple events DDS 1.4 open
DDS15-243 Dispose for topics without key DDS 1.4 open
DDS15-242 set_expression_parameters on ContentFilteredTopic, MultiTopic DDS 1.4 open
DDS15-241 Clarify when a dispose or unregister may be omitted for a Reader DDS 1.4 open
DDS15-238 Add restrictions and guidelines that are required when writing GROUP coherent sets DDS 1.4 open
DDS15-239 Add resource limits related to coherent changes DDS 1.4 open
DDS15-237 How to handle some GROUP ordered Subcriber scenarios DDS 1.4 open
DDS15-236 Request/Offered behavior of DURABILITY Qos does not match use-cases DDS 1.4 open
DDS15-234 Incorporate common elements from DDS Security to the Builtin Topics DDS 1.4 open
DDS15-208 Add DataTagQosPolicy DDS 1.4 open
DDS15-209 Define ranges of QosPolicyId_t DDS 1.4 open
DDS15-207 Durability section typos DDS 1.4 open
DDS15-206 BuiltinTopicKey_t should be completely customizable. DDS 1.4 open
DDS15-205 Specify behavior of filters and queries relative of lifecycle events DDS 1.4 open
DDS15-204 Add API for "directed writes" DDS 1.4 open
DDS15-203 Topic Names are Restricted to Characters, Digits, and Hyphens DDS 1.4 open
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-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-196 Clarify RxO behavior for DURABILITY Qos DDS 1.4 open
DDS15-190 Specify Publishers with PRESENTATION access_scope GROUP should use same order for DataWriters DDS 1.4 open
DDS15-29 All IDL should use local interfaces DDS 1.4 open
DDS15-187 Durability Implementation Description does not consider the role of partitions DDS 1.4 open

Issues Descriptions

Define InstanceHandle_t and DomainId_t portably

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

    Define InstanceHandle_t as a structure that contains native data
    Define DomainId_t as an integer

  • Reported: DDS 1.4 — Mon, 5 Aug 2019 11:57 GMT
  • Updated: Thu, 10 Oct 2019 00:04 GMT

Names of listener operations are incorrect in UML diagrams

  • Key: DDS15-247
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    In Figures 2.9, 2.10, and 2.17, the Data*Listener classes in the UML incorrectly have functions called

    on_*_match()

    when in fact they should be

    on_*_matched()
  • Reported: DDS 1.4 — Thu, 14 Feb 2019 23:35 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

The start time of type Time_t is not defined

  • Key: DDS15-240
  • Status: open   Implementation work Blocked
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    Section 2.3.2 on page 138 contains:

    The two types used to represent time: Duration_t and Time_t are mapped into structures that contain fields for the second and the nanosecond parts.

    However, the standard does not define the calendar time of Time_t at

    { sec = 0, nanosec = 0 }

    .
    This is required in order to convert a Time_t to/from a system's native time (such the the type time_t on Unix systems which has the calendar start time 1970-01-01 00:00:00).

  • Reported: DDS 1.4 — Sat, 21 Jul 2018 07:19 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Collection of longs misrepresented in 2.2.1.1 MyClass

  • Key: DDS15-246
  • Status: open  
  • Source: Turkish Navy Research Center ( Akif Tokuz)
  • Summary:

    In MyClass table on page4 (pdf page 16/180), param4 is given type long. But the description says above:"‘param4,’ is also an input parameter of type collection of longs"
    So it must be "long []" instead of "long".

    I checked the DDS 1.2 spec (formal/07-01-01), it was correct in that version (pdf page 18/260).

    Akif,

  • Reported: DDS 1.4 — Thu, 3 Jan 2019 13:23 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Consider replacing @Choice annotation with XTYPES 1.2 unions

  • Key: DDS15-249
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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 1.4 — Mon, 20 May 2019 22:45 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Wrong name for DataRepresentationQosPolicy field

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

    Section 7.6.3.1.3 'DataRepresentationQosPolicy: Platform-Specific API' states:

    The topic, publication, and subscription built-in topic data types shall each indicate the data representation of the associated entity with a new member:

    @id(0x0073) DDS::DataRepresentationQosPolicy representation;

    This does not follow the naming conventions for field names. Instead it should have said that the new member should be:
    @id(0x0073) DDS::DataRepresentationQosPolicy data_representation;

    Likewise in Annex D the declarations of structures TopicBuiltinTopicData, TopicQos, PublicationBuiltinTopicData, DataWriterQos, SubscriptionBuiltinTopicData, and DataReaderQos all have the member:

    @id(0x0073) DDS::DataRepresentationQosPolicy representation;
    

    This should be changed so the member is:

    @id(0x0073) DDS::DataRepresentationQosPolicy data_representation;
    
  • Reported: DDS 1.4 — Wed, 5 Jun 2019 23:44 GMT
  • Updated: Thu, 10 Oct 2019 00:03 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: Thu, 10 Oct 2019 00:03 GMT

The DDS Specification should define legal DDS Topic Types

  • Key: DDS15-20
  • Legacy Issue Number: 19141
  • Status: open  
  • Source: ADLINK Technology Ltd ( 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: Thu, 10 Oct 2019 00:03 GMT

DURABILITY history depth should be de-coupled from the KEEP_LAST history depth used for reliability

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

    The specification provides no way to way to specify a different history depth used for DURABILITY than the used for reliability...

    The HISTORY depth is sometimes needed for reliability in order to accommodate bursts. But this means that the amount of data kept for DURABILITY is affected.

    What is desirable is to have a setting that allows the DURABILITY depth to be decoupled from the RELIABILITY.

  • Reported: DDS 1.4 — Tue, 27 Mar 2018 16:37 GMT
  • Updated: Thu, 10 Oct 2019 00:03 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: Thu, 10 Oct 2019 00:03 GMT

History and Reliability should be orthogonally independent concerns

  • Key: DDS15-25
  • Legacy Issue Number: 17284
  • Status: open  
  • Source: ADLINK Technology Ltd ( 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(n). 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: Thu, 10 Oct 2019 00:03 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: Thu, 10 Oct 2019 00:03 GMT

Extend SampleInfo with sequenceNumber and reception_timestamp

  • Key: DDS15-309
  • Status: open  
  • Source: ADLINK Technology Ltd ( Erik Hendriks)
  • Summary:

    Many vendors already extend the SampleInfo with some additional fields:

    • The reception_timestamp
    • The writerSequence number.

    I would propose we make these part of the new standard.

  • Reported: DDS 1.4 — Wed, 25 Sep 2019 20:15 GMT
  • Updated: Wed, 25 Sep 2019 20:15 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: Mon, 23 Sep 2019 15:42 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: Tue, 27 Aug 2019 23:25 GMT

PARTITION PolicyQos should be in DataReader/DataWriter

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

    The logic of the PARTITION Qos applies separately to each DataReader/DataWriter and the propagation on the DCPS bultin Topics also happens along with each DataReader and DataWriter.

    Despite this the PARTITION Qos can only be set on the Publisher/Subscriber which impact all the DataWriters/DataReaders they contain. To overcome this we have seen many users create a separate Publisher/Subscriber per DataWriter/DataReader which unnecessarily consumes resources and couples them.

    The recommendation is to allow the PARTITION Qos to be set directly on the DataWriter and DataReader. This would not impact the behavior of partition matching. Just makes it more flexible to use.

    A question is whether we should still allow the Publisher/Subscriber to have a PARTITION Qos. This may be desirable to avoid braking existing code. In this case we could interpret as a 'default" unless ta DataWriter/DataReader specifies it explicitly. This would make current applications work without changes.

  • Reported: DDS 1.4 — Fri, 16 Aug 2019 00:54 GMT
  • Updated: Mon, 19 Aug 2019 14:27 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: Fri, 16 Aug 2019 00:09 GMT

Deprecate Basic Service Mapping

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

    The Basic Service Mapping was included in the specification primarily to support implementations that did not support XTYPES. Now that most DDS support XTYPES this motivation is no longer there.

    Having both a Basic Service Mapping and an Enhance Service Mapping creates significant complexity and ambiguity. It becomes another choice the user must make and another way implementations may not interoperate.

    Furthermore when other specifications map to DDS Services, they must too make a choice of Service Mappings. Hence perpetuating complexity and interoperability issues.

    The Enhanced Service Mapping has significant advantages in terms of performance, scalability, and type-system simplicity. Fundamentally it allows the use of the same types for request reply and RPC, any extra information is added in meta-data so that the types themselves are unpolluted. This is in-line with what other middleware technologies (e.g. JMS) does.

    Therefore the most sensible thing is to deprecate the Basic Service Mapping.

  • Reported: DDS 1.4 — Mon, 20 May 2019 22:31 GMT
  • Updated: Thu, 15 Aug 2019 00:50 GMT

Align with XTYPES 1.3 and IDL 4.2

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

    This issue should be treated as blocker so that it is resolved ahead of other issues.

    • Align naming of annotations with the latest versions of said specifications.
    • Use the new size-aware typenames: int32_t, uint32_t etc. Instead of the classic ones.
    • Use bitmask where it makes sense. For example the StatusKind, InstanceStateKind, ViewStateKind and the corresponding
    • StatusMask, InstanceStateMask, ViewStateMask? Will this negatively impact /break the Java, C#, C++ APIs?
    • Use enum for ReturnCode_t, QosPolicyId_t? Will this negatively impact /break the Java, C#, C++ APIs?
    • Use template modules to model the Implied IDL related to type 'Foo'?
    • Apply the @extensibility annotation to the BuiltinTopicData types and the types they reference (e.g. QosPolicy types) since they are serialized to be sent to other peers. Note that this was already done in XTYPES so we can copy those definitions to the DDS spec and remove them from a future revision of XTYPES.
  • Reported: DDS 1.4 — Mon, 20 May 2019 22:47 GMT
  • Updated: Wed, 7 Aug 2019 11:37 GMT

Organize definitions of Time_t, Duration_t and other common types in the PIM

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

    The PIM contains definitions for most of the "reference semantic" classes. But it does not directly define the "value semantic" classes such as: Time_t, Duration_t, SequenceNumber_t, InstanceHandle_t, StatusKind, StatusMask, etc.

    Some types like ReturnCode_t are defined. But this is done in an odd place: (section 2.2.1.1 'Format and Conventions').

    The PIM would be more clear if these types were all defined clearly in a centralized place. For example the Infrastructure module.

    This issue should be treated as a "Blocker" so it is resolved ahead of other issues. That way the other issues can refer to the new definitions and organization.

  • Reported: DDS 1.4 — Wed, 7 Aug 2019 11:03 GMT
  • Updated: Wed, 7 Aug 2019 11:03 GMT

Add a DomainTag to the PSM

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

    RTPS 2.4 added a domainTag (see Table 8.73 - RTPS SPDPdiscoveredParticipantData attributes) this was done to support having the DDS RTF adding it to the next version of the Spec. This task should be completed.

    The domainTag is used to isolate domains even if they are on the same DDS domainId

  • Reported: DDS 1.4 — Mon, 5 Aug 2019 12:22 GMT
  • Updated: Mon, 5 Aug 2019 12:22 GMT

What can be done with a disabled Topic?

  • Key: DDS15-255
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Since Topics are Entities, they can exist in a disabled state. Section 2.2.2.1.1.7 is insufficient to define what can (more importantly, can't) be done with a disabled Topic.
    That section defines which operations "may be invoked on it", but more interesting for Topics are the passive uses of these objects as arguments to other operations.
    In particular, it should be explicitly stated that a DataReader or Writer that references a disabled Topic (including, for readers, indirectly via ContentFilteredTopic or MultiTopic) cannot be enabled. In these cases, the enable() operation returns RETCODE_PRECONDITION_NOT_MET.

  • Reported: DDS 1.4 — Tue, 9 Jul 2019 15:56 GMT
  • Updated: Tue, 9 Jul 2019 15:56 GMT

Specify the behavior of instance state machine in case of a disconnect-reconnect scenario

  • Key: DDS15-254
  • Status: open  
  • Source: ADLINK Technology Ltd ( Erik Hendriks)
  • Summary:

    The DDS specification is very clear what happens in case of a disconnect: the receiver will behave as if the sender unregistered all its instances. But what should the behavior be in case of a reconnect?

    For VOLATILE cases the behavior might still be intuitive: an instance stays NOT_ALIVE_NO_WRITERS until an update has been received, in which case it goes back to ALIVE. And because VOLATILE data is typically periodic data, eventually all my instances will come back alive.

    But what about non-volatile data, that is typically not periodic, or is periodic but with a very low update frequency? Consider the following scenario:

    • Writer A writers 10 samples belonging to 10 different instances.
    • Reader B takes all samples.
    • Writer A disconnects from Reader B.
    • Reader B receives invalid samples indicating all instances are now NOT_ALIVE_NO_WRITERS.
    • Reader B takes these samples.
    • A reconnection is established, and none of the instances have been updated by Writer A.

    You would expect that all instances in Reader B would go back to the ALIVE state, but how do I get them back into the ALIVE state? Since there are no more samples to piggy-bag this instance state change on.

    A couple of approaches are conceivable:

    • Use an invalid sample to bring the instance back alive.
    • Republish the last available sample
    • Do nothing.

    Every approach has its pro's and cons, but the DDS spec should clearly describe which behavior is intended here.

  • Reported: DDS 1.4 — Wed, 19 Jun 2019 12:15 GMT
  • Updated: Wed, 19 Jun 2019 12:15 GMT

Consider adding some of the concepts in the new PSMs to the PIM

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

    Examples:

    • Selector from C++ PSM
    • Cascading operations to set Qos policies qos.with().with().
    • Dispatch on waitset and conditions (attach a function)
    • "close" operation that is recursive and avoids having a handle to the factory.
      *
  • Reported: DDS 1.4 — Wed, 19 Jun 2019 10:00 GMT
  • Updated: Wed, 19 Jun 2019 10:00 GMT

Clarify definition of counts in Plain Communication Status

  • Key: DDS15-252
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    The second table in 2.2.4.1 (the one that starts with "SampleLostStatus") has confusing definitions of the "counts" in various plain communication status.

    Certain "statuses" simply report events that occur within the Entities. Sample Lost is a good example of this. When a sample is lost, it's lost for good and not coming back. Therefore we expect total_count_change to be nonnegative. In this case the total_count definition is clear.

    Other "status" are ways to report some aspect of the state of the Domain to the application. Inconsistent Topic is an example of this. Since remote Entities can change at any time, the count of inconsistent topics may decrease (for example, when a Topic owned by a remote Participant is deleted). For the "statuses" in this category, the wording of the definition of total_count (and perhaps other attributes) is confusing since it starts with "Total cumulative count..." just like the one for Sample Lost.

  • Reported: DDS 1.4 — Fri, 7 Jun 2019 15:36 GMT
  • Updated: Fri, 7 Jun 2019 15:36 GMT

Clarify the PartitionQosPolicy

  • Key: DDS15-245
  • Status: open  
  • Source: Kongsberg Defence & Aerospace ( Havard Skjevling)
  • Summary:

    It is ambiguous whether or not the PartitionQosPolicy set for a Publisher or Subscriber should affect DataWriter and DataReader matching, and how an implementation should handle it.

    Since it is stated that failure to match partitions does not imply "incompatible" QoS, it would seem it does not affect matching.
    If so, the specification should be clearer with regards to

    • whether this is filtered on the publishing, or subscribing side (or both)
    • how partitions are tied to samples or instances e.g. when written from a DataWriter whose Publisher changes partitions intermittently
    • how it deals with late joiners and historical data
    • how this affects the "transient/persistent" services and their entities' QoS settings

    2.2.3 QosPolicy Table

    A DataWriter within a Publisher only communicates with a DataReader in a Subscriber if (in addition to matching the Topic and having compatible QoS) the Publisher and Subscriber have a common partition name string.

    2.2.3.13 Partitions

    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. Each string in the list that defines this QoS policy defines a partition name. A partition name may
    contain wildcards. Sharing a common partition means that one of the partition names matches.
    Failure to match partitions is not considered an “incompatible” QoS and does not trigger any listeners nor conditions.

  • Reported: DDS 1.4 — Wed, 7 Nov 2018 11:03 GMT
  • Updated: Tue, 27 Nov 2018 20:58 GMT

Communication Status changes for multiple events

  • Key: DDS15-244
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Plain Communication Status structures may undergo multiple changes between the time the first event occurs and when the application reads/resets the Plain Communication Status. This results in loss of important data that DDS should make available to the application. It is more likely to occur when using the WaitSet/StatusCondition mechanism instead of Listeners, but may occur with Listeners depending on how the implementation determines when to invoke the Listener.

    For example, an application creates a DataReader that uses Deadline QoS. In order to monitor for Deadline violations, the application gets the reader's StatusCondition and adds it to a WaitSet. If that Condition becomes active, the application invokes get_requested_deadline_missed_status to determine which instance experienced the deadline violation (using last_instance_handle). However, in the case that multiple instances have deadline violations since the last time status was checked (total_count_change > 1), the identity of all but the last of those instances is not available to the application.

    This same concept applies to any of the uses of "last_*" in the Plain Communication Status structures.

  • Reported: DDS 1.4 — Tue, 2 Oct 2018 17:44 GMT
  • Updated: Tue, 2 Oct 2018 17:44 GMT

Dispose for topics without key

  • Key: DDS15-243
  • Status: open  
  • Source: Central Research Laboratory, Bharat Electronics Ltd ( Saurabh Bansal)
  • Summary:

    Behavior of dispose is not specified for topics without key.
    As per section "2.2.1.2.2 Overall Conceptual Model",. If no key is provided, the data set associated with the Topic is restricted to a single instance.

    If data set is considered as a single instance than dispose of that instance shall be possible.

  • Reported: DDS 1.4 — Wed, 19 Sep 2018 17:08 GMT
  • Updated: Thu, 20 Sep 2018 17:58 GMT

set_expression_parameters on ContentFilteredTopic, MultiTopic

  • Key: DDS15-242
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    When expression parameters change, should any data stored in associated DataReaders be re-evaluated using the new parameters? Or do the DataReaders reflect the state of the parameters at the time the data was received?

  • Reported: DDS 1.4 — Wed, 22 Aug 2018 20:27 GMT
  • Updated: Wed, 22 Aug 2018 20:27 GMT

Clarify when a dispose or unregister may be omitted for a Reader

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

    If a writer disposes an instance that it never sent to a reader, should it still send the dispose to the reader?

    In general sending it would cause an scalability problem. So it would be better not to.

    However there are cases where it may be needed. For example if a Writer sets an alarm and a different writer that never created it wants to dispose it.

    Perhaps this behavior something is something that should be configurable on the Reader or Writer.

  • Reported: DDS 1.4 — Wed, 8 Aug 2018 15:25 GMT
  • Updated: Wed, 8 Aug 2018 17:47 GMT

Add restrictions and guidelines that are required when writing GROUP coherent sets

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

    RTPS 2.4 added support for GROUP ordered access and coherent access. As part of this effort, a number of restrictions and guidelines were identified that should be added to DDS in order to properly support these features.

    The restrictions include:

    • Writers shall not be created and/or deleted from the time a GROUP Publisher called begin_coherent_changes() to end_coherent_changes()
    • Readers belonging to a subscriber with PRESENTATION access_scope=GROUP must all have the same value for DESTINATION_ORDER, RELIABILITY?, DURABILITY, OWNERSHIP
    • Writers belonging to a Publisher with PRESENTATION access_scope=GROUP should have the same value for OWNERSHIP, DURABILITY, RELIABILITY?, DESTINATION_ORDER?
      • With OWNERSHIP: kind (i.e. all SHARED or all EXCLUSIVE) and in the case they are exclusive all Writers must have value of the the same OWNERSHIP_STRENGTH.
    • All samples in the coherent set should have the same reception_timestamp and source_timestamp:
      • If access_scope = GROUP the reception and source timestamp are equal to that of the EndCoherentChanges sample.
      • If access_scope < GROUP the reception and source timestamp correspond to the ones from the last sample in the coherent set which may or may not be the EndCoherentChanges sample.

    Guidelines:

    • Adding a note for users that it may often be required to change the HISTORY kind/depth from KEEP_LAST,1. This is because a publisher that is quickly publishing coherent sets which update the same instances could very easily invalidate a coherent set that has not been fully delivered to the subscribers. Replacing a sample in history that is part of a coherent set invalidates that coherent set. It may be worth adding a callback that is called when a writer removes a coherent set from its queue
      • In general, writers that are part of a GROUP Publisher should be configured homogeneously.
  • Reported: DDS 1.4 — Fri, 20 Jul 2018 16:55 GMT
  • Updated: Fri, 20 Jul 2018 17:49 GMT

Add resource limits related to coherent changes

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

    RTPS 2.4 added support for GROUP ordered access and coherent access. It may be useful to consider adding some resource limits specifically associated with coherent sets.
    For example, limiting the maximum number of samples that can be outstanding per DataReader and per Subscriber.

    These resource limits would help to prevent a (potentially ill-intentioned) Writer from filling up the entire reader queue with a never-ending coherent set since the reader must store the coherent set until it is complete.

  • Reported: DDS 1.4 — Fri, 20 Jul 2018 16:58 GMT
  • Updated: Fri, 20 Jul 2018 17:49 GMT

How to handle some GROUP ordered Subcriber scenarios

  • Key: DDS15-237
  • Status: open  
  • Source: ADLINK Technology Ltd ( Erik Hendriks)
  • Summary:

    When using a GROUP ordered Subscriber, how do you access the samples in the order in which they are produced? The DDS1.4 specification says the following thing about this:.

    "If the PRESENTATION QosPolicy of the Subscriber to which the DataReader belongs has the access_scope set to ‘GROUP.’ This operation should only be invoked inside a begin_access/end_access block. Otherwise it will return the error PRECONDITION_NOT_MET. Depending on the setting of the PRESENTATION QoS policy (see 2.2.3.6), the returned collection of DataReader objects may be a ‘set’ containing each DataReader at most once in no specified order, or a ‘list’ containing each DataReader one or more times in a specific order.

    1. If PRESENTATION access_scope is INSTANCE or TOPIC the returned collection is a ‘set.’
    2. If PRESENTATION access_scope is GROUP and ordered_access is set to TRUE, then the returned collection is a ‘list.’
      This difference is due to the fact that, in the second situation it is required to access samples belonging to different DataReader objects in a particular order. In this case, the application should process each DataReader in the same order it appears in the ‘list’ and read or take exactly one sample from each DataReader. The patterns that an application should use to access data is fully described in 2.2.2.5.1, Access to the data."

    The big question here is: what happens when the user does not follow this scenario exactly? Here is a couple of potential deviations from the described scenario:

    1. Reading more than one sample from every listed reader (i.e. use read/take with max_samples > 1)
      • We could state that no matter what the size of max_samples is, you get one sample at max.
    2. Reading/Taking samples with different sample/view/instance state masks than passed to the get_datareaders() call.
    3. Reading/Taking samples from a different reader than next one in the reader list.
    4. you invoke get_datareaders() before having fully iterated through the previous reader list.

    We should specify what happens if an application (intentionally or non-intentionally) does not follow the scenario laid out in the spec, or we should come up with an alternative reading mechanism that does not allow you stray off the correct path in these ways for example by introducing new function calls.

  • Reported: DDS 1.4 — Fri, 6 Jul 2018 19:34 GMT
  • Updated: Fri, 6 Jul 2018 19:34 GMT

Request/Offered behavior of DURABILITY Qos does not match use-cases

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

    The DURABILITY Qos is defined as Request/Offered. If a DataWriter offers a kind, the DataReader 'request' kind must be 'less or equal'. Otherwise they will not match, for this comparison it is considered that
    VOLATILE < TRANSIENT_LOCAL < TRANSIENT < PERSISTENT.

    This is not intuitive to users and does not match many of the use-cases observed in practice.

    What users expect is for a DataWriter to configure its durability without impact on the matching (very much like HISTORY). The setting would just control whether the DataWriter keeps a local copy of the data for late joiners and whether it sends the data to the persistence services.

    The reader in the other hand should simple state whether it wants "historical data" meaning data that was published before the reader joined the domain. This could just be a "boolean" or maybe a boolean plus some extra information that controls how much "historical data" to get.

    If the DataWriter enabled durability then it would get the data that the DataWriters have on their "historical cache" that includes data from the Persistence services.

    If a DataWriter set DURABILITY to TRANSIENT or PERSISTENT, then it would send its data to the PERSISTENCE services. It it was 'TRANSIENT LOCAL" then the Persistence service would not match the writer.

    Ideally this could be done as an extension so it has minimal impact in current behavior or interoperabiity

  • Reported: DDS 1.4 — Tue, 27 Mar 2018 20:09 GMT
  • Updated: Tue, 27 Mar 2018 20:09 GMT

Incorporate common elements from DDS Security to the Builtin Topics

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

    DDS Security added information to the builtin-topic data.
    Some if this information is generic and not specific to DDS Security. An example of this is DataTags. Even if those are things DDS Security can associate permissions with, the tags themselves are generic and would make sense for any DDS implementation.

    The purpose of this issue is to identify those "generic" additions made by DDS Security and incorporate them to the DDS specification.

  • Reported: DDS 1.4 — Wed, 7 Mar 2018 19:02 GMT
  • Updated: Wed, 7 Mar 2018 19:02 GMT

Add DataTagQosPolicy

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

    The DDS Security specification (see 7.2.5) added a DataTagQosPolicy defined as:

    @extensibility(APPENDABLE)
    struct Tag {
        string name;
        string value;
    };
    
    typedef sequence<Tag> TagSeq;
    
    @extensibility(APPENDABLE)
    struct DataTags {
        TagSeq tags;
    };
    
    typedef DataTags DataTagQosPolicy
    

    This is actually a generic policy that does not require DDS Security. It makes sense even without security as a way to associate tags with DataWriters and DataReaders.

    Therefore it would be better to move that definition to the DDS specification. This is a user-visible API that is expected to be explicitly set. If it is not part of the DDS API than applications would not be directly portable between DDS and DDS security.

    The spec should also define values for DATATAG_QOS_POLICY_NAME and DATATAG_QOS_POLICY_ID. For example:

     const string DATATAG_QOS_POLICY_NAME = "DataTag";
     const QosPolicyId_t  DATATAG_QOS_POLICY_ID = 25;
    

    Note that currently DDS-XTYPES defines IDs 23 and 24. Probably XTYPES should have used numbers in a different range so the IDs in DDS could remain contiguous.

    See also DDS15-209.

  • Reported: DDS 1.4 — Thu, 18 Jan 2018 23:05 GMT
  • Updated: Thu, 18 Jan 2018 23:14 GMT

Define ranges of QosPolicyId_t

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

    DDS defines values of QosPolicyId_t from 0 to 22. Other specs (e.g. XTYPES) define additional values (23 and 24) and vendors potentially also define values.

    To avoid confusion and collision DDS should allocate ranges for each of these. For example:
    0-499 for DDS
    500-999 for Other OMG specs
    1000- for vendor extensions.

    If we go with this proposal we need to file an issue with XTYPES to change the policy ID values to to the reserved range for "other specifications"

  • Reported: DDS 1.4 — Thu, 18 Jan 2018 23:13 GMT
  • Updated: Thu, 18 Jan 2018 23:13 GMT

Durability section typos

  • Key: DDS15-207
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    2.2.3.4 DURABILITY

    paragraph 5: "serviced" should be "service"

    paragraph 8: "data-instances" should be "data-instance"

    item #3: "longer that" should be "longer than"

    last paragraph: "disposition" should be "disposal" or "dispose operation"

  • Reported: DDS 1.4 — Thu, 14 Dec 2017 22:54 GMT
  • Updated: Thu, 14 Dec 2017 22:54 GMT

BuiltinTopicKey_t should be completely customizable.

  • Key: DDS15-206
  • Status: open  
  • Source: ADLINK Technology Ltd ( Erik Hendriks)
  • Summary:

    The IDL file describing the builtin topics consists of two parts:

    • A section with #define statements where certain datatypes may be customized by the different vendors.
    • A section where these customized datatypes are actually embedded in the builtin topic declarations.

    All builtin topics contain a key field of type BuiltinTopicKey_t that is defined in the following way:

    #define BUILTIN_TOPIC_KEY_TYPE_NATIVE long
    
    module DDS {
        struct BuiltinTopicKey_t {
            BUILTIN_TOPIC_KEY_TYPE_NATIVE value[3];
        };
    };
    

    This implies that vendors may specify part of the key (the array element type), but they may not specify it to be anything else than an array of three of those vendor specific datatypes.

    Right now, different vendors have specified the BuiltinTopicKey_t in various different ways: some uses an array of 16 octets to directly reflect the RTPS GUID, but the official DDS spec does not allow for this.

    In order to allow for these kinds of vendor specific customizations, the entire BuiltinTopicKey_t should be declared as a vendor specific #define statement.

    As some context: this issue was filed in the RTPS RTF working group during the Dec 2017 San Fransisco OMG meeting. Basically the consensus was that indeed the builtin topic key type should be fully customizable. How this is exactly gonna be achieved was left to the DDS RTF working group.

  • Reported: DDS 1.4 — Tue, 5 Dec 2017 19:50 GMT
  • Updated: Wed, 6 Dec 2017 07:00 GMT

Specify behavior of filters and queries relative of lifecycle events

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

    How are dispose and unregister samples treated for DataReaders that use a ContentFilteredTopic or a QueryCondition?

    Should these "lifecycle" notification samples pass all filters? Should the "key part" of the filter be considered when propagating these notifications?

  • Reported: DDS 1.4 — Tue, 5 Dec 2017 18:50 GMT
  • Updated: Tue, 5 Dec 2017 18:50 GMT

Add API for "directed writes"

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

    The DDS-RTPS protocol supports directing samples to a specific DataReader. However there is no way to exercise this feature using standard DDS API.

    The idea is to add an additional operation to the DataWriter allowing the specification of the destination DataReader. This could be a specific write_directed() operation or a more generic write_with_parameters() that allows additional parameters to be specified.

  • Reported: DDS 1.4 — Sat, 2 Dec 2017 00:33 GMT
  • Updated: Sat, 2 Dec 2017 00:34 GMT

Topic Names are Restricted to Characters, Digits, and Hyphens

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

    SQL grammar in BNF in clause B.2 limits topic names to the following characters: [A-Za-z0-9\-]+.

    The DDS specification should add support for more characters. Some candidates are "/", ":", ".", "_". The latter is actually used in the DDS-XTYPES as a separator in the mapping of interfaces to request and reply topics.

  • Reported: DDS 1.4 — Tue, 28 Nov 2017 16:13 GMT
  • Updated: Thu, 30 Nov 2017 14:35 GMT

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

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

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

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

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

Durability Implementation Description does not consider the role of partitions

  • Key: DDS15-187
  • Legacy Issue Number: 19649
  • Status: open  
  • Source: ADLINK Technology Ltd ( 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