Data Distribution Service Avatar
  1. OMG Specification

Data Distribution Service — Closed Issues

  • Acronym: DDS
  • Issues Count: 166
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
DDS-178 ref-1003: Section 3.1.3.2 (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-176 ref-1001: section 3.1.1 (editorial DDS 1.0b1 DDS 1.0 Resolved closed
DDS-177 ref-1002: section 3.1.2.1 (editorial DDS 1.0b1 DDS 1.0 Resolved closed
DDS-175 Missing operations to allow the navigation described in the PIM DDS 1.0b1 DDS 1.0 Resolved closed
DDS-174 Bad references DDS 1.0b1 DDS 1.0 Resolved closed
DDS-173 DDS editorial issues DDS 1.0b1 DDS 1.0 Resolved closed
DDS-172 Changing the IDL module DDS 1.0b1 DDS 1.0 Resolved closed
DDS-170 ref-1054: Bad which_added operations in IDL DDS 1.0b1 DDS 1.0 Resolved closed
DDS-171 ref-1053 Missing is_composition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-169 Missing operations on DomainParticipantFactory and need for helper values DDS 1.0b1 DDS 1.0 Resolved closed
DDS-168 New definition for Selections DDS 1.0b1 DDS 1.0 Resolved closed
DDS-167 ref-171 Rename_Topic_USER_DATA_to_TOPIC_DATA DDS 1.0b1 DDS 1.0 Resolved closed
DDS-166 Ref-170 Missing_description_of_OWNERSHIP_STRENGH DDS 1.0b1 DDS 1.0 Resolved closed
DDS-165 New definition for ObjectListener DDS 1.0b1 DDS 1.0 Resolved closed
DDS-163 Several instead one listener DDS 1.0b1 DDS 1.0 Resolved closed
DDS-162 clone + deref DDS 1.0b1 DDS 1.0 Resolved closed
DDS-164 delete clone DDS 1.0b1 DDS 1.0 Resolved closed
DDS-161 Mapping DCPS-DLRL DDS 1.0b1 DDS 1.0 Resolved closed
DDS-158 Naming of the private members DDS 1.0b1 DDS 1.0 Resolved closed
DDS-160 New definition for ObjectFilter DDS 1.0b1 DDS 1.0 Resolved closed
DDS-159 clean_modified (in ObjectRoot, Relations...) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-157 New structure for DLRLOid DDS 1.0b1 DDS 1.0 Resolved closed
DDS-156 ObjectRoot::is_modified (clarification) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-155 ObjectHome index and name DDS 1.0b1 DDS 1.0 Resolved closed
DDS-154 ref-1032: User-provided oid DDS 1.0b1 DDS 1.0 Resolved closed
DDS-153 DDS ISSUE# 57] Clarify creation of waitset and conditions DDS 1.0b1 DDS 1.0 Resolved closed
DDS-150 DDS ISSUE# 55] Rename DataType interface to TypeSupport DDS 1.0b1 DDS 1.0 Resolved closed
DDS-152 Ref-224 Built_in_topics_not_in_PSM DDS 1.0b1 DDS 1.0 Resolved closed
DDS-151 DDS ISSUE# 56] Missing fields in builtin topics DDS 1.0b1 DDS 1.0 Resolved closed
DDS-149 Ref-231 Provide_a_way_to_limit_count_returned_samples DDS 1.0b1 DDS 1.0 Resolved closed
DDS-148 DDS ISSUE# 54] Refactor or extend API used to access samples DDS 1.0b1 DDS 1.0 Resolved closed
DDS-147 Ref-113 Meta_sample_accounting_towards_resource_limits DDS 1.0b1 DDS 1.0 Resolved closed
DDS-146 Ref-112 Value_of_data_for_DISPOSED_state DDS 1.0b1 DDS 1.0 Resolved closed
DDS-144 DDS ISSUE# 53] Refactor lifecycle state DDS 1.0b1 DDS 1.0 Resolved closed
DDS-143 DDS ISSUE# 52] Provide for zero copy access to data DDS 1.0b1 DDS 1.0 Resolved closed
DDS-145 Ref-85 Garbage_collection_of_disposed_instances DDS 1.0b1 DDS 1.0 Resolved closed
DDS-142 DDS ISSUE# 49] Behavior_of_register_type DDS 1.0b1 DDS 1.0 Resolved closed
DDS-141 Rename DataType interface to TypeSupport DDS 1.0b1 DDS 1.0 Resolved closed
DDS-140 DDS ISSUE# 46] Use of RETCODE_NOT_IMPLEMENTED DDS 1.0b1 DDS 1.0 Resolved closed
DDS-139 DDS ISSUE# 45] Is OMG IDL PSM more correct than CORBA PSM? DDS 1.0b1 DDS 1.0 Resolved closed
DDS-138 DDS ISSUE# 44] Errors in figures DDS 1.0b1 DDS 1.0 Resolved closed
DDS-137 Ref-139 Bad_reference_to filter_expression DDS 1.0b1 DDS 1.0 Resolved closed
DDS-134 DDS ISSUE# 41] Inconsistent use of instance in datawriter api DDS 1.0b1 DDS 1.0 Resolved closed
DDS-136 DDS ISSUE# 43] Bad references DDS 1.0b1 DDS 1.0 Resolved closed
DDS-133 DDS ISSUE# 40] Expression syntax is missing enumeration DDS 1.0b1 DDS 1.0 Resolved closed
DDS-135 DDS ISSUE# 42] Clarify how counts in the status accumulate DDS 1.0b1 DDS 1.0 Resolved closed
DDS-132 DDS ISSUE# 39] Combine module names DDS 1.0b1 DDS 1.0 Resolved closed
DDS-131 DDS ISSUE# 38] Allow application to install a clock DDS 1.0b1 DDS 1.0 Resolved closed
DDS-130 DDS ISSUE# 37] SAMPLE_LOST_STATUS on DataReader DDS 1.0b1 DDS 1.0 Resolved closed
DDS-127 Ref-144 User_data_on_topic DDS 1.0b1 DDS 1.0 Resolved closed
DDS-128 Ref-142 Confusing_description_of_manual_by_participant DDS 1.0b1 DDS 1.0 Resolved closed
DDS-126 Ref-165 Make_USER_DATA_changeable DDS 1.0b1 DDS 1.0 Resolved closed
DDS-123 Ref-109 Destination_order_should_be_request_offered DDS 1.0b1 DDS 1.0 Resolved closed
DDS-129 Ref-162 Separate_transient_into_two_kinds DDS 1.0b1 DDS 1.0 Resolved closed
DDS-125 Ref-144 Wrong_description_of_compatible_DURABILITY DDS 1.0b1 DDS 1.0 Resolved closed
DDS-122 Ref-108 Ownership_interaction_with_deadline DDS 1.0b1 DDS 1.0 Resolved closed
DDS-120 Ref-156 Clarify_TIME_BASED_FILTER DDS 1.0b1 DDS 1.0 Resolved closed
DDS-121 Ref-106 Desc_of_Inconsistent_topic_status::total_count_change DDS 1.0b1 DDS 1.0 Resolved closed
DDS-124 Ref-111 Default_values_for_qos DDS 1.0b1 DDS 1.0 Resolved closed
DDS-119 Ref-104 Coupling_bwn_TIME_BASED_FILTER_and_RELIABILITY DDS 1.0b1 DDS 1.0 Resolved closed
DDS-117 Ref-210 Clarification_of_responsibility_of_RxO_qos DDS 1.0b1 DDS 1.0 Resolved closed
DDS-114 DDS ISSUE# 34] Initial data when DataWriter appears DDS 1.0b1 DDS 1.0 Resolved closed
DDS-118 Ref-212 Qos_Coupling_TimeBasedFilter_deadline DDS 1.0b1 DDS 1.0 Resolved closed
DDS-115 Inconsistency on what operations may return NOT_ENABLED DDS 1.0b1 DDS 1.0 Resolved closed
DDS-111 DDS ISSUE# 31] Topic QoS refactor DDS 1.0b1 DDS 1.0 Resolved closed
DDS-116 DDS ISSUE# 36] QoS clarifications DDS 1.0b1 DDS 1.0 Resolved closed
DDS-113 DDS ISSUE# 33] Initialization of resources needed DDS 1.0b1 DDS 1.0 Resolved closed
DDS-112 DDS ISSUE# 32] Create dependencies on type DDS 1.0b1 DDS 1.0 Resolved closed
DDS-110 DDS ISSUE# 30] Setting of default qos on factories DDS 1.0b1 DDS 1.0 Resolved closed
DDS-108 [DDS ISSUE# 28] Desirability to define "information model" in a file DDS 1.0b1 DDS 1.0 Resolved closed
DDS-106 DDS ISSUE# 26] Definition of DCPSKey DDS 1.0b1 DDS 1.0 Resolved closed
DDS-109 DDS ISSUE# 29] Disposing a multi-topic DDS 1.0b1 DDS 1.0 Resolved closed
DDS-107 DDS ISSUE# 27] Additional situations resulting in inconsistent QoS DDS 1.0b1 DDS 1.0 Resolved closed
DDS-104 DDS ISSUE# 24] Clarification of status flag DDS 1.0b1 DDS 1.0 Resolved closed
DDS-101 Ref-134 Additional_w_timestamp_operations DDS 1.0b1 DDS 1.0 Resolved closed
DDS-105 DDS ISSUE# 25] Addition of read and take to ReadCondition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-103 ISSUE# 23] Make Listener inheritance explicit in figures 2-9 and 2-10 DDS 1.0b1 DDS 1.0 Resolved closed
DDS-102 DDS ISSUE# 22] Details in the code generation DDS 1.0b1 DDS 1.0 Resolved closed
DDS-100 DDS ISSUE# 21] Helper operations DDS 1.0b1 DDS 1.0 Resolved closed
DDS-99 DDS ISSUE# 20] Narrow the applicability of assert liveliness DDS 1.0b1 DDS 1.0 Resolved closed
DDS-96 DDS ISSUE# 17] Clarify consequence of changing partitions DDS 1.0b1 DDS 1.0 Resolved closed
DDS-98 DDS ISSUE# 19] Initial value of entity status changes DDS 1.0b1 DDS 1.0 Resolved closed
DDS-95 DDS ISSUE# 16] Clarification of expression syntax DDS 1.0b1 DDS 1.0 Resolved closed
DDS-97 Behavior on creation failure DDS 1.0b1 DDS 1.0 Resolved closed
DDS-94 DDS ISSUE# 15] Semantics of register and unregister instance DDS 1.0b1 DDS 1.0 Resolved closed
DDS-92 Ref-118 Introduce_TIME_INVALID_constant DDS 1.0b1 DDS 1.0 Resolved closed
DDS-93 Ref-102 Addition_of time_related_constants DDS 1.0b1 DDS 1.0 Resolved closed
DDS-91 DDS ISSUE# 14] Helper addition to the IDL DDS 1.0b1 DDS 1.0 Resolved closed
DDS-87 Use of Topic versus TopicDescription DDS 1.0b1 DDS 1.0 Resolved closed
DDS-90 Ref-31 Reason_and_use_of_enabled DDS 1.0b1 DDS 1.0 Resolved closed
DDS-89 Reason and use of enable DDS 1.0b1 DDS 1.0 Resolved closed
DDS-88 Ref-40 Name_and_return_type_of_lookup_topic DDS 1.0b1 DDS 1.0 Resolved closed
DDS-86 Duplicate use of domainId DDS 1.0b1 DDS 1.0 Resolved closed
DDS-85 Ref-02 Data_Available_status_transition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-83 Ref-229 IDL_rename_publisher_laxity_w_latency_budget DDS 1.0b1 DDS 1.0 Resolved closed
DDS-82 Ref-63 QoS_USER_DATA_on_Publisher_and_Subscriber DDS 1.0b1 DDS 1.0 Resolved closed
DDS-84 Clarification of listener invocation and waitset signaling DDS 1.0b1 DDS 1.0 Resolved closed
DDS-81 Ref-135 Missing_accessor_for_SampleRejectedStatus DDS 1.0b1 DDS 1.0 Resolved closed
DDS-80 Ref-126 Inconsistent_parameter_order_to_get_datareaders DDS 1.0b1 DDS 1.0 Resolved closed
DDS-75 Ref-59 FooDataReader_read_take_parameter_order DDS 1.0b1 DDS 1.0 Resolved closed
DDS-76 Ref-70 Missing_deadline_statuskind_from_pim DDS 1.0b1 DDS 1.0 Resolved closed
DDS-79 Ref-205 On_requested_deadline_missed_paramtype DDS 1.0b1 DDS 1.0 Resolved closed
DDS-74 Ref-58 DataReader_read_take_w_condition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-73 Ref-56 Subscriber_notify_datareaders_parameters DDS 1.0b1 DDS 1.0 Resolved closed
DDS-72 Ref-57 FooDataReader_get_key DDS 1.0b1 DDS 1.0 Resolved closed
DDS-71 Ref-49 DataWriter_get_key DDS 1.0b1 DDS 1.0 Resolved closed
DDS-78 Ref-88 Inconsistent_naming_PIM_IDL_instance_samples DDS 1.0b1 DDS 1.0 Resolved closed
DDS-77 Ref-79 Missing_StatusKind_liveliness_idl_constants DDS 1.0b1 DDS 1.0 Resolved closed
DDS-70 Ref-48 FooDataWriter_unregister_instance DDS 1.0b1 DDS 1.0 Resolved closed
DDS-65 Ref-28 IDL_entity_get_statuscondition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-69 Ref-46 ContentFilteredTopic_related_topic DDS 1.0b1 DDS 1.0 Resolved closed
DDS-67 Ref-37 Entity_ specialization_set_get_listener_in_idl DDS 1.0b1 DDS 1.0 Resolved closed
DDS-66 Ref-34 Incorrect_guard_condition_enabled_statuses DDS 1.0b1 DDS 1.0 Resolved closed
DDS-68 Ref-42 DomainParticipantListener_on_requested DDS 1.0b1 DDS 1.0 Resolved closed
DDS-64 Ref-39 Entity_specialization_set_get_qos DDS 1.0b1 DDS 1.0 Resolved closed
DDS-63 Inconsistencies between PIM and PSM/IDL DDS 1.0b1 DDS 1.0 Resolved closed
DDS-61 Entity specialization of set/get qos/listener DDS 1.0b1 DDS 1.0 Resolved closed
DDS-62 Ref-36 Entity_specialization_set_get_qos DDS 1.0b1 DDS 1.0 Resolved closed
DDS-60 Single waitset attached to condition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-55 Ref-20 Semantics_of_factory_delete_methods DDS 1.0b1 DDS 1.0 Resolved closed
DDS-59 Ref-15 Behavior_on_deletion_from_wrong_factory DDS 1.0b1 DDS 1.0 Resolved closed
DDS-57 Ref-151 No_locally_duplicate_topics DDS 1.0b1 DDS 1.0 Resolved closed
DDS-53 Ref-62 Return_type_of_set_query_operations DDS 1.0b1 DDS 1.0 Resolved closed
DDS-56 Ref-87 Clarify_Topic_deletion_as_local_concept DDS 1.0b1 DDS 1.0 Resolved closed
DDS-58 Ref-22 Automatic_deletion_of_contained_entities DDS 1.0b1 DDS 1.0 Resolved closed
DDS-52 Naming_of_attribute_getter_operations DDS 1.0b1 DDS 1.0 Resolved closed
DDS-51 Potential problems in PSM mappings DDS 1.0b1 DDS 1.0 Resolved closed
DDS-50 Obtaining the DomainParticipantFactory DDS 1.0b1 DDS 1.0 Resolved closed
DDS-54 Delete dependencies and semantics DDS 1.0b1 DDS 1.0 Resolved closed
DDS-46 ObjectHome::get_topic_name (editorial DDS 1.0b1 DDS 1.0 Resolved closed
DDS-47 ObjectHome::get_all_topic_names (addition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-45 stringSeq and longSeq (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-48 Operations on collections of objects (addition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-49 Name of ObjectLink (consistency) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-44 CacheAccess::deref (clarification) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-43 CacheAccess::delete_access (editorial DDS 1.0b1 DDS 1.0 Resolved closed
DDS-41 Depth of cloning (addition) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-42 CacheAccess operations (documentation) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-40 Names of the ObjectRoot attributes DDS 1.0b1 DDS 1.0 Resolved closed
DDS-36 Additional_qos_LIFESPAN Issue DDS 1.0b1 DDS 1.0 Resolved closed
DDS-39 : Attributes and operations directly set on valuetypes DDS 1.0b1 DDS 1.0 Resolved closed
DDS-38 CacheFactory::find_cache (addition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-35 Additional_qos_DATA_PRIORITY Issue DDS 1.0b1 DDS 1.0 Resolved closed
DDS-37 Make_USER_DATA_an_array_and_mutable Issue DDS 1.0b1 DDS 1.0 Resolved closed
DDS-33 Writer_notification_of_delivery_failure Issue DDS 1.0b1 DDS 1.0 Resolved closed
DDS-34 Navigation_of_connectivity_information Issue DDS 1.0b1 DDS 1.0 Resolved closed
DDS-31 Extension_to_the_partition_qos DDS 1.0b1 DDS 1.0 Resolved closed
DDS-32 Transactional_reliability Issue DDS 1.0b1 DDS 1.0 Resolved closed
DDS-30 Attributes_on_a_topic_description DDS 1.0b1 DDS 1.0 Resolved closed
DDS-29 Additional_communication_paradigms DDS 1.0b1 DDS 1.0 Closed; No Change closed
DDS-26 ref-1017: Section 3.1.4.4.2 topic (editorial DDS 1.0b1 DDS 1.0 Resolved closed
DDS-28 ref-1019: Name of the ObjectRoot::clone method (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-25 ref-1016: Page 3-65 t2 (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-24 ref-1015: Page 3-62 manual edition (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-27 ref-1018: Name of the methods for ObjectListener (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-22 ref-1013: Section 3.1.6.3.9 Table for ObjectQuery (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-23 ref-1014: Page 3-10, figure 3-2 min_topic (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-19 ref-1010: Section 3.2.3.3 XML Model Tags of the example DDS 1.0b1 DDS 1.0 Resolved closed
DDS-21 ref-1012: Section 3.2.3.3 Simplified XML of the example) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-18 ref-1009: Section 3.2.3.2 IDL Model description of the example DDS 1.0b1 DDS 1.0 Resolved closed
DDS-15 ref-1006: Page 3.11 (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-20 ref-1011: Section 3.2.3.3 Introduction to figure 3.9 (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-14 ref-1005: figure 3.2 (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-17 ref-1008: Bad annex reference (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-16 ref-1007: Section 3.1.6.3.4 CacheListener (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-13 ref-1004: Section 3.1.3.3 Metamodel (clarification) DDS 1.0b1 DDS 1.0 Resolved closed

Issues Descriptions

ref-1003: Section 3.1.3.2 (editorial)

  • Key: DDS-178
  • Legacy Issue Number: 6707
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The last paragraph is a note, but is not is the note style
    Proposal [THALES]
    Correct the footprint

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Wed, 11 Mar 2015 01:53 GMT

ref-1001: section 3.1.1 (editorial

  • Key: DDS-176
  • Legacy Issue Number: 6705
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    In the final editing process, "native-language constructs" has become "native-language data-accessing constructs". However, the mentioned constructs are not only related to accessing the data (e.g., creation of an object)
    Proposal [THALES]
    Remove the extra "data-accessing"

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Wed, 11 Mar 2015 01:53 GMT

ref-1002: section 3.1.2.1 (editorial

  • Key: DDS-177
  • Legacy Issue Number: 6706
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Starting at "A DLRL object has at least one shared attribute..." (page 3-3), the whole section has been messed up during the final editing process; therefore, the content is no more understandable.
    Proposal [THALES]
    Restore the wording and footprint as it was in version V67 (the last Word one)

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Missing operations to allow the navigation described in the PIM

  • Key: DDS-175
  • Legacy Issue Number: 6687
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-200 Figure_2_10_arrow_readcondition
    The PIM indicates by means of the arrow pointing from ReadCondition to DataReader that navigation is possible. However, the navigation is not present in the PSM (no operation, no attribute).
    Proposal: Fix by adding get_datareader() operation to the ReadCondition. This operation should take no arguments and return a DataReader
    Ref-201 Figure_2_5_arrow_statuscondition
    The PIM indicates by means of the arrow pointing from StatusCondition to Entity that navigation is possible. However, the navigation is not present in the PSM (no operation, no attribute).
    Proposal: Fix by adding get_entity() to StatusCondition. This operation should take no arguments and return a Entity.
    Ref-202 Figure_2_10_arrow_topicdescription
    The PIM indicates by means of the arrow pointing from DataReader to TopicDescription that navigation is possible. However, the navigation is not present in the PSM (no operation, no attribute).
    Proposal: Fix by adding get_topicdescription to DataReader. This operation should take no arguments and return a Topicdescription.
    Ref-203 Figure_2_9_arrow_topic
    The PIM indicates by means of the arrow pointing from DataWriter to Topic that navigation is possible. However, the navigation is not present in the PSM (no operation, no attribute).
    Proposal: Fix by adding get_topic() to DataWriter. This operation should take no arguments and return a Topic.
    Ref-227 Missing_navigation_operations
    The PIM indicates by means of the arrow pointing from DataReader to Subscriber, from DataWriter to Publisher, and from DomainEntity to Participant that navigation is possible. However, the navigation is not present in the PSM (no operation, no attribute)
    Proposal: Fix by adding DataReader::get_subscriber (no parameters, returns a Subscriber), DataWriter::get_publisher (no parameters, returns a Publisher), and the operations Publisher:: get_participant(), Subscriber::get_participant, and TopicDescription::get_participant() (these 3 operations should take no arguments and return a Participant). It is not needed to add get_participant to DataReader or DataWriter because it is possible to navigate to the subscriber/publisher and from there to the participant.

  • Reported: DDS 1.0b1 — Mon, 8 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Bad references

  • Key: DDS-174
  • Legacy Issue Number: 6686
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    DDS ISSUE# 2 Bad references
    Ref-67 Bad_reference_to_SubscriberFactory
    Sections 2.1.5, 2.1.6.2.1, and 2.1.6.2.2. Mention a SubscriberFactory. There is no SubscriberFactory. They should mention DomainParticipant. instead
    Proposal: Replace SubscriberFactory with DomainParticipant in said sections.
    Ref-71 Bad_reference_to_CORBA_PIM
    Section 2.2.2. Says "The CORBA PIM is provided by means of the IDL that defines the interface an application can use to interact with the Service."
    This should be: "The CORBA PSM ..."
    Proposal: Replace as stated above
    Ref-80 Bad_reference_to_appendixA
    On page 2-21, 2-22, 2-28, 2-29, 2-54, 2-59 all the references to appendix A should be references to appendix B
    Proposal: Replace as stated above

  • Reported: DDS 1.0b1 — Mon, 8 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Wed, 11 Mar 2015 01:53 GMT

DDS editorial issues

  • Key: DDS-173
  • Legacy Issue Number: 6685
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-66 Misplacing_of_key_in_builtin_topic_table
    Section 2.1.5. Fields "key" with Topic DCPSPublication and DCPSSubscription are placed one row to high compared to the relating Topic. In other words, DCPSPublication and DCPSSubscription should be placed one row higher.
    The thickness of the lines between the rows might suggest some relation between fields, but is implemented inconsequent.
    Proposal: Correct table as described above.
    Ref-103 Typo_on_section_2.1.2.5.2.8
    3rd paragraph Says "... prior to calling any of the sample-accessing operations, namely: … on the DataWriter"
    Should say "on the DataReader" instead of "on the DataWriter"
    Proposal: Replace "DataWriter" with "DataReader" in said paragraph
    Ref-105 Typo_on_section_2.1.3.11
    Section 2.1.3.11 says "Assuming the STRENGTH policy allows it…"
    Should say "Assuming the OWNERSHIP policy allows it…"
    Proposal: Replace as stated above
    Ref-115 Typo_consistent_use_of_term_publication
    Section 2.1.2.2.1.15 says "The publication to ignore"… The parallel sentence in section 2.1.2.2.1.16 says the "The DataReader to ignore"…
    These two sentences should be consistent
    Proposal: Replace "publication" with DataWriter in 2.1.2.2.1.15
    Ref-143 Typo_on_RELIABILITY_description
    In Section 2.1.3, QoS table. The description of RELIABILITY in the last line it says "and whether a samples can be discarded from it." Should say "samples" instead of "a samples"
    Proposal: Replace as stated above
    Ref-145 Bad_reference_to_DCPSEntity
    Section 2.1.3 Figure 15 Says DCPSEntity instead of Entity in one of the lines
    Proposal: Replace as stated above
    Ref-147 Typo_on_section_2.1.5
    Section 2.1.5 third paragraph says: The last "r" in "get_datareader" is not using italics as it should within the sentence "The built-in DataReader objects can be retrieved by using the operation get_datareader, with the Subscriber and the topic name as parameters."
    Proposal: Make the "r" italic.
    Ref-207 Grammar_errors_on_secs_2.1.2.4_and_2.1.2.5
    2.1.2.4.2.6: 2nd paragraph, 1st line: "one" should be "once" according to 2.1.2.1.1.7 this should be the case.
    2.1.2.5.2.8: 3rd paragraph, 3rd line: "....on any DataWriter" should be "....on any DataReader"
    2.1.2.5.3.8: Point 5, 3rd line: "....that is required that.... " should be "....that it is required that.....""
    Proposal: Fix above 3 typos as stated above
    Ref-221 Typo_on_section_2.1.4.4
    2.1.4.4: First paragraph after the bullets:"... is done after
    ininitial is at ion phase..." should be "... is done after initialization phase..."
    Proposal: Fix as stated above
    Ref-228 Typo_on_2.1.2.2.1.13
    2.1.2.2.1.13 2nd paragraph, 4th line: "filed" should be "field"
    Proposal: Fix as stated above

  • Reported: DDS 1.0b1 — Mon, 8 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Changing the IDL module

  • Key: DDS-172
  • Legacy Issue Number: 7169
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

    The module names in the IDL are very terse and not prefixed. In
    this form they pose a high risk of a name collision with any other,
    even user-written, IDL module. I would suggest to prefix the module
    names as explained in the IDL Style Guide (ab/98-06-03). The "Cos"
    prefix would be adequate. This means to change for example
    "module DDS" to "module CosDDS", or even to a more intuitive
    "module CosDataDistributionService" for the benefit of the user.
    I think non of today's systems has a severe name limitation
    anymore.

    Further email narrowed the proposal to "CosDDS".

    Proposed action: No Change

    Both RTI and THALES feel that the change significantly affect users that
    have started developing applications using the API. Our companies have
    invested significantly in the API and a change this late would make us
    lose a lot of credibility and may really upset some customers. In the
    case of RTI this includes documentation that has been in-use by
    customers over the last 6 months.

    In our respective markets there is a lot of people using C and C++ with
    compilers that don't support name-spaces so this change affects a very
    visible part of the API, namely the prefix of every function. The change
    may appear small but it may actually have big impact if we consider
    user-acceptance.

    Furthermore, the use of the "Cos" prefix may be misleading as the
    Data-Distribution Service was designed so it would be implementable
    without an object service.

  • Reported: DDS 1.0b1 — Tue, 30 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 21:40 GMT

ref-1054: Bad which_added operations in IDL

  • Key: DDS-170
  • Legacy Issue Number: 7134
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The "which_added" operations on the collections were designed in the PIM so
    that it is possible not to compute any result when the content of the
    collection had been totally changed. This is not present in the IDL. *** Proposal [THALES]
    change the operation to get a boolean result (true => the information is
    returned in the out parameter; false => no information) instead of sending
    the information as the result.

        • Concrete changes
          IDL
          abstract valuetype ListBase : CollectionBase {
          boolean which_added (out LongSeq indexes);
          [instead of LongSeq which_added ();]
          ...
          abstract valuetype StrMapBase : CollectionBase {
          boolean which_added (out StringSeq keys);
          [instead of StrinSeq which_added ();]
          ...
          abstract valuetype IntMapBase : CollectionBase {
          boolean which_added (out LongSeq keys);
          [instead of LongSeq which_added ();]
  • Reported: DDS 1.0b1 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:40 GMT

ref-1053 Missing is_composition

  • Key: DDS-171
  • Legacy Issue Number: 7136
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The is_composition operation is described in the PIM, but is not in the IDL.
    It concerns the valuettype RefRelation, ListRelatrion, IntMapRelation, and
    StrMapRelation.

        • Proposal
          add the following operation
          boolean is_composition(); on those valuetypes
  • Reported: DDS 1.0b1 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:40 GMT

Missing operations on DomainParticipantFactory and need for helper values

  • Key: DDS-169
  • Legacy Issue Number: 7100
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The resolution of issue 6816 added operation to get and set default QoS on all the entity factories except for the DomainParticipantFactory. This was an omission as this factory also needs to provide these operation such that DomainParticipant entities can also be created using default QoS.
    The operation lookup_participant is defined in the PIM (section 2.1.2.2.2) and does not appear in the PSM
    Furthermore, it would be desirable to have some utility constants in the IDL that can be used to indicate to the factory that default QoS should be used to construct an entity. This avoids having to explicitly get the default QoS in the case the application does not want to change any of the defaults. Helper constants can also be added for the specific case of constructing DataReader and DataWriter entities when the application wishes to indicate that the QoS should be obtaining by modifying the default values with the ones defined by the Topic Qos

  • Reported: DDS 1.0b1 — Mon, 8 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:40 GMT

New definition for Selections

  • Key: DDS-168
  • Legacy Issue Number: 7067
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    As notification_scope has been removed from the ObjectHome (cf. issue ref-1049), it is necessary to pass the information whether the modification of objects inside a Selection should be appreciated only on the object basis, or on the object + its contained objects basis
    clarification is requested regarding when the SelectionListener is activated
    Proposal [THALES]
    add a parameter concerns_contained when the Selection is created and add this characteristic in the selection attributes
    add a paragraph to specify when the Selection Listener is activated
    in SelectionListener::on_object_out, the ObjectRoot may no more exist, therefore passing the ObjectReference is better
    Concrete changes
    in IDL
    local interface Selection

    { ... readonly attribute boolean concerns_contained; [addition] ... }

    ;
    local interface SelectionListener

    { ... [the following method is no more commented out for it will not be redefined in the derived implied IDL] void on_object_out ( in ObjectReference the_ref); [instead in ObjectRoot the_object] }

    ;
    in section 3.1.6.3.7 Selection
    in the table, attribute list, add the following entry (as third attribute)
    concerns_contained boolean
    in the following text, starting with "It has the following attributes:"
    add the following text at the end of the second bullet:
    "; it is given at Selection creation time(cf. ObjectHome::create_selection)"
    add a bullet in third position, with the following content:
    "a boolean concerns_contained that indicates whether the Selection considers the modification of one of its members based on its content only (FALSE) or based on it content or the content of its contained objects (TRUE); it is given at Selection creation time(cf. ObjectHome::create_selection);"
    add at the end of the section, the following paragraph:
    "The SelectionListener is activated when the composition of the Selection is modified or when one of its members is modified. A member can be considered as modified, either only when it is itself modified or when itself or one of its contained objects is modifie (depending on the value of concerns_contained). Modifications in the Selection are considered with respects to the state of the Selection last time it was examined, i.e.:
    add one bullet with the following text:
    " at each incoming updates processing if autro_refresh is TRUE;"
    add a second bullet with the following text:
    "at each explicit call to refresh, if auto-refresh is FALSE."

  • Reported: DDS 1.0b1 — Thu, 4 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:40 GMT

ref-171 Rename_Topic_USER_DATA_to_TOPIC_DATA

  • Key: DDS-167
  • Legacy Issue Number: 7066
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The resolution of issue 6833 added USER_DATA QoS to Topic.
    However this name overlaps with the USER_DATA on the DataWriter and DataReader and prevents an application from using both at the same time.

    **PROPOSAL**
    Rename USER_DATA on Topic to be TOPIC_DATA.
    This involves adding a TOPIC_DATA QoS that concerns Topic, DataReader and DataWriter
    Add topic_data as a field in the DCPSTopic, DCPSPublication and DCPSSubscription tables describing the built-in topics in section 2.1.5, page 2-90.

  • Reported: DDS 1.0b1 — Wed, 3 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:40 GMT

Ref-170 Missing_description_of_OWNERSHIP_STRENGH

  • Key: DDS-166
  • Legacy Issue Number: 7064
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.3 "Supported QoS" is missing a subsection that describes the OWNERSHIP_STRENGH QoS policy

    ***Proposal ***
    Add section 2.1.3.7 with the text:

    2.1.2.3.7 OWNERSHIP_STRENGH
    This QoS policy should be used in combination with the OWNERSHIP policy. It only applies to the situation case where OWNERSHIP kind is set to EXCLUSIVE.
    The value of the OWNERSHIP_STRENGTH is used to determine the ownership of a data-instance (identified by the key). The arbitration is performed by the DataReader. The rules used to perform the arbitration are described in Section 2.1.3.6.2 .

  • Reported: DDS 1.0b1 — Wed, 3 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:40 GMT

New definition for ObjectListener

  • Key: DDS-165
  • Legacy Issue Number: 7062
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    ref-1049: New definition for ObjectListener
    Issue [THALES]
    When a contained object is modified, it can be difficult to get the information in the ObjectListener
    In all cases, getting the old value seems useful in certain cases,
    As first parameter, the ObjectReference is more appropriate tah the ObjectRoot, for the object may not be instanciated; in addition, this simplifies because it is no more mandatory to generate the implied FooListener.
    Whether the notification concerns the object or the object + its contained object should be set on a Listener basis, rather than on the ObjectHome basis.

  • Reported: DDS 1.0b1 — Thu, 26 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Several instead one listener

  • Key: DDS-163
  • Legacy Issue Number: 7060
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    Currently there is only one ObjectHome and one Cache Listeners. This has been considered by users as fairly limited and as several selections are allowed, unjustified
    Proposal [THALES]
    Allow several listeners.
    Precise the triggering order
    Concrete changes
    IDL
    local interface Selection {
    ...
    SelectionListener set_listener (
    in SelectionListener listener);
    [instead attach_listener in the commented out section]
    ...
    local interface Cache {
    ...
    readonly attribute CacheListenerSeq listeners;
    [instead readonly attribute CacheListener listener]
    ...
    void detach_listener (
    in CacheListener listener);
    [instead no parameter]
    ...
    local interface ObjectHome {
    ...
    readonly attribute ObjectListenerSeq listeners;
    [instead readonly attribute ObjectListener listener]
    ...
    void detach_listener (
    in ObjectListener listener);
    [instead no parameter]
    ...
    in section 3.1.6.3.3 Cache
    in the table
    list of attributes replace the entry for listener by the following
    listeners CacheListener []
    list of operations, replace the entry for detach_listener by the following
    detach_listener void
    listener CacheListener
    in section 3.1.6.3.5 ObjectHome
    in the table
    list of attributes replace the entry for listener by the following
    listeners ObjectListener []
    list of operations, correct the entry for attach_listener by the following (ObjectListener instead of Listener)
    attach_listener void
    listener ObjectListener
    list of operations, replace the entry for detach_listener by the following
    detach_listener void
    listener ObjectListener
    in section 3.1.6.3.7 Selection
    in the table, change the entries for attach_listener and detach_listener to only one operation set_listener, as follows:
    set_listener SelectionListener
    listener SelectionListener
    in the following text, in the list starting with "it offers the methods to:"
    change the first bullet to:
    "set the listener (set_listener) that will be triggered when the composition of the selection changes as well as if one of its members is modified; set_listener returns the previously set listener if any; set_listener, called with a NULL parameter discards the current listener."
    in section 3.1.6.4.1 General Scenario
    In the list starting with "This set of updates is managed as follows"
    change the first bullet to:
    "First, all the CacheListener::start_updates operations are triggered; the order in which these listeners are triggered is not specified"
    change the last bullet to:
    "Finally all the CacheListener::end_updates operations are triggered and the modification state of the object are cleaned; the order in which these listeners are triggered is not specified."
    in section 3.1.6.4.2 Object Creation
    In the list
    change the first bullet to:
    "First, the ObjectListener suitable to that object are searched and their on_object_created operations triggered; the search follows the inheritance structure starting from the more specific ObjectHome (e.g., FooHome, for an object typed Foo) to ObjectRoot. The search is stopped when all on_object_created operations at one level return true; inside one level the triggering order is not specified."
    in section 3.1.6.4.3 ObjectModification
    In the list
    change the last bullet to:
    "Then, the ObjectListener suitable to that object are searched and their on_object_modified operations triggered; the search follows the inheritance structure starting from the more specific ObjectHome (e.g., FooHome, for an object typed Foo) to ObjectRoot. The search is stopped when all on_object_modified operations at one level return true; inside one level the triggering order is not specified."
    in section 3.1.6.4.4 ObjectDeletion
    In the list
    change the last bullet to:
    "the ObjectListener suitable to that object are searched and their on_object_deleted operations triggered; the search follows the inheritance structure starting from the more specific ObjectHome (e.g., FooHome, for an object typed Foo) to ObjectRoot. The search is stopped when all on_object_deleted operations at one level return true; inside one level the triggering order is not specified."

  • Reported: DDS 1.0b1 — Thu, 26 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

clone + deref

  • Key: DDS-162
  • Legacy Issue Number: 7059
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    ref-1041: clone + deref
    Issue [THALES]
    For performance, it seems good to offer a combined operation clone + deref that returns the instantiated cell instead the ObjectReference
    Proposal [THALES]
    Add such a method on ObjectRoot and also in the implied IDL
    Concrete changes:
    IDL
    ObjectRoot {
    ...
    ObjectRoot clone_object(
    in CacheAccess access,
    in ObjectScope scope,
    in RelatedObjectDepth depth)
    raises (
    ReadOnlyMode,
    AlreadyClonedInWriteMode);
    Foo {
    ...
    Foo clone_foo(
    in CacheAccess access,
    in ObjectScope scope,
    in ReletedObjectDepth depth)
    raises (
    ReadOnlyMode,
    AlreadyClonedInWriteMode);
    in section 3.1.6.3.11 ObjectRoot
    in the table, add the clone_object operation, by adding the following:
    clone_object ObjectRoot
    access CacheAccess
    scope ObjectScope
    depth integer
    in the following text, in the list starting with "it offers methods to":
    insert a second bullet, with the following contents:
    "clone and instantiate the object in the same operation (clone_object), this operations takes the same parameters as the previous one, but returns an ObjectRoot instead of an ObjectReference; it corresponds exactly to the sequence of clone followed by CacheAccess::deref on the reference returned by the clone operation;"
    in section 3.1.6.5.1 Read Mode
    item #2, change "(ObjectRoot::clone)" to "(ObjectRoot::clone or clone_object)"
    in section 3.1.6.5.2 Write Mode
    item #2, change "(ObjectRoot::clone)" to "(ObjectRoot::clone or clone_object)"

  • Reported: DDS 1.0b1 — Thu, 26 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

delete clone

  • Key: DDS-164
  • Legacy Issue Number: 7061
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    ref-1046: delete_clone
    Issue [THALES]
    Useful to remove a clone from a CacheAccess in addition to the deletion of all the clones.
    Proposal [THALES]
    add an operation on CacheAccess to delete a clone
    should concern the object itself + all its components, but not the related objects (regardless to what was the clone request)
    Concrete changes
    IDL
    local interface CacheAccess {
    ...
    void delete_clone(
    in ObjectReference ref);
    ...
    in section 3.1.6.3.2 CacheAccess
    in the table, after the purge operation, insert the delete_clone operation, by insetring the following entries:
    delete_clone void
    ref ObjectReference
    in the following text,
    introduce a bullet, before the last one, with the following content:
    "alternatively, the copy of one object and all its attached contained objects can be detached from the CacheAccess (delete_clone);"

  • Reported: DDS 1.0b1 — Thu, 26 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping DCPS-DLRL

  • Key: DDS-161
  • Legacy Issue Number: 7058
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Currently the specified mapping is rather strict with respects to the mapping between the DLRLOid and the DCPS topic keys. When an existing DCPS schema is reused, more flexibility would be desirable
    In particular, there exist cases when there are no DCPS keys at all (should correspond to a singleton class)
    In some circumstances, the indication of the class name while needed in the main topic (to guess what is the type of the corresponding object) is not needed in the relations to objects of that type

  • Reported: DDS 1.0b1 — Mon, 1 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming of the private members

  • Key: DDS-158
  • Legacy Issue Number: 7025
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    All private members should be named consistently starting by m_
    Concerns m_ref and m_refs in Relation
    Proposal [THALES]
    change the names
    Concrete changes
    IDL
    valuetype RefRelation {
    private ObjectReference m_ref;
    [instead ref]
    valuetype ListRelation : ListBase {
    private ObjectReferenceSeq m_refs;
    [instead refs]
    valuetype IntMapRelation : StrMapBase {
    ...
    private ItemSeq m_refs;
    [instead refs]
    valuetype IntMapRelation : StrMapBase {
    ...
    private ItemSeq m_refs;
    [instead refs]

  • Reported: DDS 1.0b1 — Wed, 25 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

New definition for ObjectFilter

  • Key: DDS-160
  • Legacy Issue Number: 7057
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]:
    Selection could be slightly enhanced, by providing to the filter the fact if the object was previously a member.
    proposal [THALES]
    carry the fact that the object was previously part of the selection to the filter so that it may return quicker the result when appropriate
    Concrete changes
    IDL
    enum MembershipState

    { UNDEFINED_MEMBERSHIP, ALREADY_MEMBER, NOT_MEMBER }

    ;

    local interface ObjectFilter

    { /*IMPLIED* boolean check_object ( in Object an_object, in MembershipState membership_state); [addition of this parameter] *IMPLIED*/ }

    ;
    in section 3.1.6.3.8 ObjectFilter
    in the table, add a parameter to the check_object operation by adding the following entry:
    membership_state enum MembershipState
    in the following text, add the following text to the bullet
    [check ... (check_object);] this method is called with s first parameter the object to be checked and as second parameter an indication whether the object previously passed the filter (membership_state); this last parameter (which is actually an enumeration with three possible values - UNDEFINED_MEMBERSHIP, ALREADY_MEMBER and NOT_MEMBER) is useful when the ObjectFilter is attached to a Selection to allow the writing of optimized filters.
    ref-1051: New definition for Selections (clarification)
    Issue [THALES]
    As notification_scope has been removed from the ObjectHome (cf. issue ref-1049), it is necessary to pass the information whether the modification of objects inside a Selection should be appreciated only on the object basis, or on the object + its contained objects basis
    clarification is requested regarding when the SelectionListener is activated
    Proposal [THALES]
    add a parameter concerns_contained when the Selection is created and add this characteristic in the selection attributes
    add a paragraph to specify when the Selection Listener is activated
    in SelectionListener::on_object_out, the ObjectRoot may no more exist, therefore passing the ObjectReference is better
    Concrete changes
    in IDL
    local interface Selection

    { ... readonly attribute boolean concerns_contained; [addition] ... }

    ;
    local interface SelectionListener

    { ... [the following method is no more commented out for it will not be redefined in the derived implied IDL] void on_object_out ( in ObjectReference the_ref); [instead in ObjectRoot the_object] }

    ;
    in section 3.1.6.3.7 Selection
    in the table, attribute list, add the following entry (as third attribute)
    concerns_contained boolean
    in the following text, starting with "It has the following attributes:"
    add the following text at the end of the second bullet:
    "; it is given at Selection creation time(cf. ObjectHome::create_selection)"
    add a bullet in third position, with the following content:
    "a boolean concerns_contained that indicates whether the Selection considers the modification of one of its members based on its content only (FALSE) or based on it content or the content of its contained objects (TRUE); it is given at Selection creation time(cf. ObjectHome::create_selection);"
    add at the end of the section, the following paragraph:
    "The SelectionListener is activated when the composition of the Selection is modified or when one of its members is modified. A member can be considered as modified, either only when it is itself modified or when itself or one of its contained objects is modifie (depending on the value of concerns_contained). Modifications in the Selection are considered with respects to the state of the Selection last time it was examined, i.e.:
    add one bullet with the following text:
    " at each incoming updates processing if autro_refresh is TRUE;"
    add a second bullet with the following text:
    "at each explicit call to refresh, if auto-refresh is FALSE."

  • Reported: DDS 1.0b1 — Mon, 1 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

clean_modified (in ObjectRoot, Relations...)

  • Key: DDS-159
  • Legacy Issue Number: 7026
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    These operations are error-prone when there are called by the developer.
    Proposal [THALES]
    suppress them and specify that the internal cleaning of modifications is performed after the last call to listeners
    Concerns the interfaces
    ObjectRoot
    CollectionBase (was CollectionOperations)
    RefRelation (was ReferenceOperations)
    Concrete changes:
    IDL
    suppress the following operations
    ObjectRoot::clean_modified
    CollectionBase::clean_modified
    RefRelation::clean_modified
    in section 3.1.6.3.11 ObjectRoot
    in the table, suppress the 2 lines that describe the operation clean_modified
    in the following list of methods (starting with "it offers methods to") suppress the last bullet
    in section 3.1.6.3.13 Reference
    in the table, suppress the 2 lines that describe the operation clean_modified
    in the following list of methods (starting with "it offers methods to") suppress the last bullet
    in section 3.1.6.3.14 Collection
    in the table, suppress the 2 lines that describe the operation clean_modified
    in the following list of methods (starting with "it offers methods to") suppress the last bullet
    in section 3.1.6.4.1 General Scenario
    in the last bullet, suppress the end of the sentence "(if not already done)"
    Finally [..] of the updated objects are cleaned.

  • Reported: DDS 1.0b1 — Wed, 25 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

New structure for DLRLOid

  • Key: DDS-157
  • Legacy Issue Number: 7024
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    Just a long seems too small to express a DLRLOid
    proposal [THALES]
    Change to a structure with 2 longs, one meant to identify the creator of the Oid and one local to this creator.
    Concrete changes
    IDL
    struct DLRLOid

    { unsigned long creator_id; unsigned long local_id; }

    ;
    [instead typedef long DLRLOid]

  • Reported: DDS 1.0b1 — Wed, 25 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectRoot::is_modified (clarification)

  • Key: DDS-156
  • Legacy Issue Number: 7023
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    return of is_modified() on a newly created object is unspecified
    Proposal [THALES]
    should return false
    concerns the text
    Concrete change
    in section 3.1.6.3.11 ObjectRoot
    in the text after the table, starting with "it offers methods to:"
    last bullet, add the following sentence at the end "in case the object is newly created, this operation returns false."

  • Reported: DDS 1.0b1 — Wed, 25 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectHome index and name

  • Key: DDS-155
  • Legacy Issue Number: 7022
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    For footprint reasons an ObjectHome is designated by its index in the Cache. For convenience, the index should be an attribute of the ObjectHome
    Proposal [THALES]
    add the index readonly attribute
    return the allocated index when the home is registered
    add an operation to retrieve the home based on the index and homogeneise names of find operations
    Concrete changes:
    IDL
    interface ObjectHome {
    ...
    readonly attribute unsigned long registration_index;
    ...
    interface Cache {
    ...
    unsigned long register_home (
    in ObjectHome a_home)
    raises (
    BadHomeDefinition);
    ObjectHome find_home_by_name (
    in ClassName class_name)
    raises (
    BadParameter);
    ObjectHome find_home_by_index (
    in unsigned long index)
    raises (
    BadParameter);
    ...
    In section 3.1.6.3.3 Cache
    In the table
    Change the return type for register_home operation from "void" to "integer"
    Change the name of "find_home" to "find_home_by_name"
    add the following entry:
    find_home_by_index ObjectHome
    integer registration_index
    In the following text, starting with "It offers methods"
    first bullet: add at the end "this method returns the index under which the ObjectHome is registered by the Cache;"
    second bullet:change to "to retrieve an already registered ObjectHome, based on its name (find_home_by_name) or based on its index of registration (find_home_by_index)
    in section 3.1.6.2.3.5 ObjectHome
    in the table
    at the end of the attribute list, add the following entry
    registration_index integer
    in the following text, in the list starting by "The public attributes gives"
    add a last bullet "the index under which the ObjectHome has been registered by the Cache (cf. Cache::register_home)
    Correct the UML diagram accordingly

  • Reported: DDS 1.0b1 — Wed, 25 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1032: User-provided oid

  • Key: DDS-154
  • Legacy Issue Number: 6867
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    There is a need that the application can provide the oid of an object at creation time
    That characteristic should be provided on a class basis.

  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 57] Clarify creation of waitset and conditions

  • Key: DDS-153
  • Legacy Issue Number: 6864
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-72 Creation_of_waitset_and_guardcondition

    The DDS spec already says they are not created from a factory because
    they are intended to be base classes that will be extended by
    application-defined classes. This makes them similar to the Listener
    interfaces.

    However it would be desirable to be more explicit regarding this

    **PROPOSAL**

    State in the PSM section that WaitSet GuardCondition are to be
    implemented as classes in the native language that can be created
    using the "new" operator natural in the PSM. Furthermore, they should
    have at least a constructor that takes no arguments so that
    applications can be portable across implementations of the DDS spec.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 55] Rename DataType interface to TypeSupport

  • Key: DDS-150
  • Legacy Issue Number: 6861
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-159 Rename_the_interface_DataType

    The name DataType used in the PSM and IDL to refer to the interface
    with the "register_type"operation from which the FooDataType derives
    for each user-data type 'Foo' is causing confusion.

    People think that the FooDataType actually represents the type of the
    objects being propagated. In reality the type is 'Foo' and FooDataType
    just provides the support to intgrate 'Foo' with the middleware

    **PROPOSAL**

    Rename DataType to TypeSupport. FooDataType to FooTypeSupport

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    See issue 6848 for disposition – duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-224 Built_in_topics_not_in_PSM

  • Key: DDS-152
  • Legacy Issue Number: 6863
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The built-in Topics are defined in the PIM but not in the PSM.

    **PROPOSAL**

    Add the definition to the IDL PSM in section 2.2.3

    include structures containing the fields in the built-in topics
    described in the table in section 2.1.5

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    See issue 6862 for disposition – duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 56] Missing fields in builtin topics

  • Key: DDS-151
  • Legacy Issue Number: 6862
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-??? Missing_fields_in_builtin_topics

    It appears that definition of built-in topics in section 2.1.5 is
    missing some fields

    Related to Ref-68

    **PROPOSAL**

    Add the missing fields

    Define a concrete type for the BuiltinTopicKey_t. Make it long[3]

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-231 Provide_a_way_to_limit_count_returned_samples

  • Key: DDS-149
  • Legacy Issue Number: 6859
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Could be that the result of the read is many samples (100000s). This
    would be bad for the application.

    **PROPOSAL**

    No concrete proposal as it would be hard to represent in IDL but it
    would be nice if such API was offered.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 54] Refactor or extend API used to access samples

  • Key: DDS-148
  • Legacy Issue Number: 6858
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-74 Refactor_the_api_used_to_access_samples

    The read() and take() operations return a "one-dimensional" array of
    samples.

    For the case where the PRESENTATION.access_scope==BY_INSTANCE and
    either HISTORY.kind == KEEP_ALL or HISTORY.depth > 1 it is desirable
    that the application can easily access all the samples that correspond
    to one instance versus the samples that correspond to other
    instances. For this purpose a 2-dimensional array (or sequence) where
    a is preferable. That would allow for example to determine easily how
    many samples are for each instance (before examining all) and also
    easily examine the "first" or "last" sample of each instance without
    navigating though all the other instances

    What we would like is something like:

    struct FooSample

    { struct SampleInfo *info; struct Foo *data; }

    ;

    typedef sequence<FooSample> FooSampleSeq;

    read(out FooSampleSeq sample_seq);

    typedef sequence<FooSampleSeq>; FooSampleCollatedSeq;

    read_collated(out FooSampleCollatedSeq collated_seq);

    Data would be then accessed as

    sample_seq[i]->data;

    Or else as

    collated_seq[k][I]->data

    However t is not clear how to map this to the IDL PSM.

    **PROPOSAL**

    No concrete proposal as it would be hard to represent in IDL but it
    would be nice if such API was offered.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-113 Meta_sample_accounting_towards_resource_limits

  • Key: DDS-147
  • Legacy Issue Number: 6857
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Related to 112

    The specification does not mention whether the DISPOSED samples count
    towards the RESOURCE_LIMITS (max samples and such)

    Although this detail unspecified, it is something that would become
    observable to the user if, for some reason, an application does not
    "take" disposed samples.

    **PROPOSAL**

    State that these samples don't count towards the limits because they
    do not have "data" associated with it. Moreover in view of Ref-84
    there can be at most one such SampleInfo per instance so the
    worst-case needed resources are small and can be taken into account by
    the implementation

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-112 Value_of_data_for_DISPOSED_state

  • Key: DDS-146
  • Legacy Issue Number: 6856
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.2.5.3 of the specification does not clearly state that the
    data_value and the sample_info sequences returned by the read* and
    take* operations must be of the same length and are in one-to-one
    correspondence

    Furthermore, the specification does not describe what the element of
    the DataSeq should be when the SampleInfo states that the
    lifecycle_state is DISPOSED

    Same issue when the lifecycle_state is NO_WRITERS

    These should be clarified

    **PROPOSAL**

    This must be rephrased in accordance with the proposal in Ref-84.

    State in section 2.1.2.5.3 that both sequences are of the same length
    and in one-to-one correspondence

    State that when the that when the liveness_lifecycle is DISPOSED
    (NO_WRITERS or EXPLICIT) the last sample for the instance, that is the
    one with instance_rank==0 has no corresponding data

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 53] Refactor lifecycle state

  • Key: DDS-144
  • Legacy Issue Number: 6854
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-84 Lifecycle_state_refactor

    The precise interpretation and representation of the lifecycle and
    sample states in the specification is not clear.

    Figure 2-11 is not easy to interpret as it refers to "observable"
    lifecycles rather than representing some internal state that the
    application accesses.

    Several issues are left open such as

    Whether what happens if in the sample history of a single instance are
    new, modified, and deleted samples (i.e. the instance was disposed and
    then created again before the reader accessed it). An additional
    question is then whether the read/take will return samples belonging
    to multiple "generations" of the instance.

    How can an application determine that as a result of a single
    read/take operation multiple samples of the same instance appear. This
    may be important because the processing a new/modified sample may
    depend on the number of samples the application has for that instance.

    Also the representation of the instance_state as an enumeration:
    NEW/MODIFIED/DELETED/NO_WRITERS is not natural. If this represents the
    state of the instance, then the instance can be simultaneously
    MODIFIED and DELETED; it can be MODIFIED and have no writers,
    etc. That is logically these are not mutually exclusive

    **PROPOSAL**

    Change the description in section 2.1.2.5.1 and representation
    lifecycle as described below.

    Replace the lifecycle_state with the following two variables (flags)

    observation_lifecycle =

    {NEW, NOT_NEW}

    liveness_lifecycle =

    { ALIVE , DISPOSE_EXPLICIT, DISPOSED_NO_WRITERS }

    Define DISPOSED as the union (DISPOSED_EXPLICIT | DISPOSED_NO_WRITERS)

    The observation_lifecycle and liveness_lifecycle are independent. All
    combinations are possible. So the lifecycle may be simultaneously NEW
    & DISPOSED_EXPLICIT, NOT_NEW & ALIVE, etc.

    All the samples in the history of an instance have the same
    "lyfecycles" states. Each time a sample is received (or a loss of
    liveliness on a remote DataWriter is detected) the liveness_lifecycle
    may change. If it changes it changes for all samples belonging to the
    same instance.

    If an instance was DISPOSED (either DISPOSED_EXPLICIT or
    DISPOSED_NO_WRITERS) and a samplefor that instance is received, the
    liveness_lifecycle of the instance changes to ALIVE.

    If a sample is received for a DataWriter, indicating that the ser has
    called "dispose" for that instance then the liveness_lifecycle of the
    instance changes to DISPOSED_EXPLICIT.

    If the infrastructure detects the loss of liveness of a DataWriter for
    the instance and this is the only DataWriter writing the instance
    known to the reader then the liveness_lifecycle of the instance
    changes to DISPOSED_NO_WRITERS

    Each time the liveliness of an instance changes from ALIVE to
    DISPOSED_EXPLICIT an internal count maintained per instance
    (disposed_explicit_count) is incremented. Each time the liveliness of
    an instance changes from ALIVE to DISPOSED_NO_WRITERS an internal
    count maintained per instance (disposed_no_writers_count) is
    incremented.

    The observation_lifecycle and liveness_lifecycle as well as the
    disposed_explicit_count and disposed_no_writers_count appear in the
    SampleInfo returned when the application reads/takes samples. This
    counters are from the perpective of the DataReader and start at 0 when
    the liveness_lifecycle is NEW

    Each time the application reads or takes samples, all returned samples
    for any one instance have the same observation_lifecycle and
    liveness_lifecycle. They represents the "snapshot" of the
    corresponding values for the instance taken at the time the data is
    read or taken.

    The disposed_explicit_count and disposed_no_writers_count in
    SampleInfo are not the same. On all samples. They represent the number
    of lifecycles of each kind that the instance had gone through at the
    time the sample stored into the history queue. The application can use
    this to distinguish samples belonging to different generations. In
    addition the SampleInfo contains an additional filed. The
    "instance_rank" that specifies how many samples for the same instance
    follow in the sequence retuned as part of the read/take. This helps
    the application anticipate that more samples for the same instance
    follow. The last sample for the instance returned will always have a
    instance_rank==0

    In addition the SampleInfo contains an additional filed. The
    "generation_rank" that specifies the generation to which the sample
    belongs relative to the generations

    The observation_lifecycle, liveness_lifecycle, disposed_explicit_count
    and disposed_no_writers can be used as in the expressions used for the
    purposes of making a Query.

    Figure 2-11 should be updated to reflect the state-transitions
    described above.

    Both the read and take operations affect the
    observation_lifecycle. The first time the application reads/takes
    samples for an instance the observation_lifecycle will be NEW. After
    the observation_lifecycle will be NOT_NEW.

    Once the application reads/takes samples with the liveness_lifecycle
    DISPOSED (either EXPLICIT or NO_WRITERS), the observation_lifecycle is
    'reset' and if new samples are received for that instance the
    observation_lifecycle will be set to NEW again.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 52] Provide for zero copy access to data

  • Key: DDS-143
  • Legacy Issue Number: 6853
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-121 Add_a_return_loan_operation_to_datareader

    For high-performance it is desirable to use a zero-copy API on the
    receive side where the middleware can "loan" buffers to the
    application on the "read" or "take" operations.

    However the use of "zero-copy" requires a mechanism for the
    application to indicate that it no longer needs access to the "loaned
    buffers"

    One possibility would be to an operation DataReader::finish or
    DataReader::return_loan that takes the SampleData and SampleInfo
    sequences as parameter and indicates to the middleware that the
    application is no longer accessing the buffers in the corresponding
    sequences.

    Another possibility would be to add a separate API for read/take

    **PROPOSAL**

    No concrete proposal yet

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-85 Garbage_collection_of_disposed_instances

  • Key: DDS-145
  • Legacy Issue Number: 6855
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    In the current specification, the applications are fully responsible
    for the resource usage. Applications have means to detect when
    lifecycles end and resources can be freed. However even if
    applications are to be written correctly not all cases are covered and
    some situations potential produce garbage, that is memory that remains
    in use and never reclaimed.

    The following are potential scenarios:

    Instances become disposed but the application does not 'take' the
    sample and therefore does not allow the middleware to end the
    lifecycle and remove the state regarding the instance

    Instances that no longer have any "active" writers and consequently
    get no more samples.

    Even if the application 'takes' the disposed instance or instances
    with no writers it is not always possible for the middleware to
    reclaim the resources. This can occur in two cases; in case of the
    service keeping Transient and Persistent data and in case of
    incomplete MultiTopic samples. In both cases an immediate removal of
    samples is not desirable but eventually the samples should be removed

    On the one hand deleting the instances immediately will potentially
    cause problems since late coming readers may require the disposed
    instances, e.g. reallocating consumers requiring disposed instances to
    finish interrupted cleanup actions or MultiTopics joining Topics with
    different lifecycles.

    On the other hand the disposed instances cannot be kept
    indefinitely. Doing this will eventually flood the system, especially
    for Topics with increasing key-values.

    The solution is to keep them for a certain duration and then reclaim
    the resources the question is how long this duration should be?

    Note that, in general, just because a sample has been disposed the
    middleware cannot reclaim all the resources on it either on the writer
    side or on the reader side. For the middleware to reclaim resources it
    is necessary that the instance is also unregistered; otherwise
    disposing would automatically relinquish ownership which is not the
    desired behavior.

    This applies both to the writer side, the reader side, and/or the
    transient/persistent durability service.

    On the writer side it is therefore clear. Resources are only fully
    reclaimed when the instance is unregistered.

    So the tricky issue is how to handle the case where an instance has no
    writers, whether it had been disposed or not, whether there are
    samples in the queue or not. Nominally we notify the application of
    this event by some means (see Issue #84). The application should then
    take the samples.

    One approach would be for the middleware to keep some resources around
    for a certain duration (DISPOSE_LIFESPAN) in case this was just a
    transient situation and the instance appears again. This treats the
    DISPOSED_NO_WRITERS similarly to the DISPOSED_EXPLICIT

    **PROPOSAL**

    Add a new QoS on the DataReader called NO_WRITERS_LIFESPAN with a
    single Duration_t field "duration". It is mutable with a default
    value equal to DURATION_INFINITY. This represents the duration for
    which the DataReader should keep the knowledge of an instance once it
    detects it has NO_WRITERS.

    After the instance has no writers the middleware is not required to
    keep the information about the instance any longer than the
    NO_WRITERS_LIFESPAN. The implication is that if an instance becomes
    DISPOSED_NO_WRITERS and the application does not take the instance for
    a time that exceeds the NO_WRITERS LIFESPAN the application could miss
    the fact that the instance has DISPOSED and has no writers.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 49] Behavior_of_register_type

  • Key: DDS-142
  • Legacy Issue Number: 6849
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-161 Behavior_of_register_type

    The specification does not say what happens if the application locally
    tries to define the same "type_name" via register_type

    The case where a different DataType is being "registered" with a name
    that was already used should clearly fail

    The case where the same DataType is registered again with the same
    name could either fail or be idempotent.

    **PROPOSAL**

    State in 2.1.2.3.6 that it is a pre-condition that the same name has
    not already been used to register a different type. In case this is
    attempted the register_type() operation shall return
    PRECONDITION_ERROR

    State in 2.1.2.3.6 the documentation that it is OK to re-register the
    same DataType again with the same type_name. In this case the
    operation is idempotent and returns OK.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename DataType interface to TypeSupport

  • Key: DDS-141
  • Legacy Issue Number: 6848
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    159 Rename_the_interface_DataType

    The name DataType used in the PSM and IDL to refer to the interface
    with the "register_type"operation from which the FooDataType derives
    for each user-data type 'Foo' is causing confusion.

    People think that the FooDataType actually represents the type of the
    objects being propagated. In reality the type is 'Foo' and FooDataType
    just provides the support to intgrate 'Foo' with the middleware

    **PROPOSAL**

    Rename DataType to TypeSupport. FooDataType to FooTypeSupport

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 46] Use of RETCODE_NOT_IMPLEMENTED

  • Key: DDS-140
  • Legacy Issue Number: 6846
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-152 General_use_of_RETCODE_NOT_IMPLEMENTED

    Many operations that can return may need the additional ReturnCode_t
    NOT_IMPLEMENTED don't explicitly say so.

    **PROPOSAL**

    In section 2.1.1.1 add ReturnCode_t NOT_IMPLEMENTED to the list of
    codes any functions may return, with the provision that it only
    applies to functions that are pert of some optional compliant point.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 45] Is OMG IDL PSM more correct than CORBA PSM?

  • Key: DDS-139
  • Legacy Issue Number: 6845
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-138 CORBA_PSM_OR_OMG_IDL_PSM

    Document refers to the PSM as a "CORBA" PSM. Wouldn't it be more
    appropriate to call it the OMG IDL PSM

    **PROPOSAL**

    Change to references to OMG IDL

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 44] Errors in figures

  • Key: DDS-138
  • Legacy Issue Number: 6844
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-146 Bad_arrow_direction_in_figure_19

    Section 2.1.4.4 Figure 2-20

    The arrows between the BLOCKED and UNBLOCKED states are backwards

    **PROPOSAL**

    Reverse directions in Figure 2-20

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-139 Bad_reference_to filter_expression

  • Key: DDS-137
  • Legacy Issue Number: 6843
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.2.3.4. Says It says "filter_expression" should be
    "subscription_expression" in the sentence "The expression_parameters
    attribute is a sequence of strings that give values to the
    'parameters' (i.e. "%n" tokens) in the subscription_expression. The
    number of supplied parameters must fit with the requested values in
    the filter_expression (i.e. the number of %n tokens)."

    **PROPOSAL**

    Replace "filter_expression" with subscription_expression in Section
    2.1.2.3.4

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 41] Inconsistent use of instance in datawriter api

  • Key: DDS-134
  • Legacy Issue Number: 6840
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-116 Inconsistent_use_of_instance_in_datawriter_api

    Currently Section 2.1.2.5.1 mentions the function dispose_instance
    which does not exist.

    A broader issue is that we have functions called
    register_instance/unregister_instance, but other functions that also
    apply to an instance (dispose, write, dispose_w_timestamp,
    write_w_timestamp, etc.) do not have "instance" in their name... This
    can lead to some confusion

    **PROPOSAL**

    Rename dispose_instance to dispose

    Fix the sequence chart in figure 2.1.6.1

    Leave the register_instance alone

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 43] Bad references

  • Key: DDS-136
  • Legacy Issue Number: 6842
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    ***Ref-137 Bad_reference_to_Condition

    Section 2.1.2.1.7.1 says "StatusCondition" when it should say
    "Condition"

    **PROPOSAL** Replace StatusCondition with Condition in 2.1.2.1.7.1

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 40] Expression syntax is missing enumeration

  • Key: DDS-133
  • Legacy Issue Number: 6839
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-136 Missing_ENUMERATION_from_expression_syntax

    ENUMERATION missing from terminals of expression for
    Query/Filters/Multitopic on the appendix

    **PROPOSAL**

    Add the following to the grammars in Appendix B and C.

    Under the rule for Parameter ::=

    Add the ENUMERATION as a terminal analogous to the INTEGER value.

    In the table describing the terminals, explain that the ENUMERATION is
    named using the identifier for the enumerated member. Either using the
    plain label or if there is conflict using the
    EnumerationTypeName::EnumerationLabel

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 42] Clarify how counts in the status accumulate

  • Key: DDS-135
  • Legacy Issue Number: 6841
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-117 Deadlines_accumulate

    Some people have been confused reading the specification with regards
    to the "total" counts and whether they accumulate.

    For example, whether the "deadline count" accumulates missed
    deadlines. That is, each deadline-time period that passes without an
    instance being written increments the deadline count even if the
    application does not have time to read the status

    **PROPOSAL**

    State this more explicitly on section 2.1.4.1

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 39] Combine module names

  • Key: DDS-132
  • Legacy Issue Number: 6838
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-131 Module_name_dcps

    The specification contains two top-level module names 'DCPS' and
    'DLRL' it is desirable to not have so many modules. It will complicate
    the C mapping and and also weaken the "brand"

    We have verified that there are no naming clashes between the two
    modules so they can be combined

    **PROPOSAL**

    In section 2.2.3 replace the module name from 'DCPS' to 'DDS'

    In section 3.2.1.2 replace the module name from 'DLRL to 'DDS'

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 38] Allow application to install a clock

  • Key: DDS-131
  • Legacy Issue Number: 6837
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-114 Behavior_of_instances_when_deleting_datawriter

    What happens when an application deletes a datawriter? Do all
    registered instances become unregistered? What about samples that may
    have been written but not propagated to remote readers?

    There are two possibilities:

    Approch1 behave as if the application had crashed with regards to the
    readers. The application should have been explicit about the contained
    entities (e.g. unregister/dispose) before deleting the writer.

    Approach2 handle it as any deletion of a container entity. It is a
    pre-condition error if it has any registered instances and the entity
    is not deleted. But also we provide helper operations on the
    DataWriter to unregister_all_instances() and dispose_all_instances().

    **PROPOSAL**

    Use Approach2. Its more explicit and less error-prone.

    Also say that the infrastructure is not required to immediately
    release the resources before returning from the delete but can keep
    them around for a while until is properly has a chance to clean up its
    state, inform remote nodes, etc.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 37] SAMPLE_LOST_STATUS on DataReader

  • Key: DDS-130
  • Legacy Issue Number: 6836
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-101 Move_sample_lost_status_to_datareader

    Section 2.1.4.2 shows in a table that SAMPLE_LOST_STATUS is on the
    Subscriber. It would make more sense to have it on the Datareader. It
    is not as useful to the application to know that samples have been
    lost for DataReaders belonging to the Subscriber as it would be to
    know which DataReaders they affected.

    When we first specified this it was thought that it would be hard to
    implement as a status on the DataReader because, given that the
    samples are lost, it would not be clear which DataReader they
    affect. As it turns out the anticipated implementation difficulties
    are not there.

    **PROPOSAL**

    Remove the SAMPLE_LOST_STATUS from the status of the Subscriber and
    add it to that of the DataReader in the table in 2.1.4.2

    Also modify the PIM in section 2.1.2.5.2 and the PSM in section 2.2.3
    moving the get_sample_lost_status operation from Subscriber to
    DataReader

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-144 User_data_on_topic

  • Key: DDS-127
  • Legacy Issue Number: 6833
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Some use-cases would benefit from having USER_DATA also on Topic.

    **PROPOSAL**

    Add TOPIC_DATA to the TopicQoS with the same definition as the
    USER_DATA. The initial value should be an empty sequence

    Add topic_data as a field in the DCPSTopic in the table describing the
    built-in topics in section 2.1.5, page 2-90.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-142 Confusing_description_of_manual_by_participant

  • Key: DDS-128
  • Legacy Issue Number: 6834
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    In Section 2.1.3, QoS table

    Clarify the LIVELINESS "MANUAL_BY_PARTICIPANT". What it says is
    correct. But its getting some people confused.

    It says:

    "The Service will assume that as long as at least one Entity within
    the domain has asserted its liveliness the Entity is also alive."

    Some people are mistakenly understanding this as:

    "...at least one Entity within the domain has asserted its liveliness
    the domain is also alive."?

    So maybe its best to say:

    "The Service will assume that as long as at least one Entity within
    the domain has asserted its liveliness the other Entities in the
    domain are also alive."

    **PROPOSAL**

    Replace as stated above

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-165 Make_USER_DATA_changeable

  • Key: DDS-126
  • Legacy Issue Number: 6832
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    In Section 2.1.3, QoS table states USER_DATA is immutable.

    Many of the use-cases of the USER_DATA require the application to be
    able to change the USER_DATA dynamically.

    **PROPOSAL**

    Make USER_DATA mutable in section 2.1.3.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-109 Destination_order_should_be_request_offered

  • Key: DDS-123
  • Legacy Issue Number: 6829
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    In order to support the BY_SOURCE_TIMESTAMP setting the DataWriter
    needs to take appropriate actions (e.g. embed timestamps). Therefore
    the DESTINATION_ORDER QoS should follow the same request/offered
    pattern other QoSs do.

    **PROPOSAL**

    Modify the QoS table in section 2.1.3 and add DataWriter as in the
    "Concerns" column for DESTINATION_ORDER. Also replace with "Yes" in
    the "RxO" (request/offered) column.

    Add a paragraph to section 2.1.3.11 stating the request/offered
    compatibility as follows:

    The value offered is considered compatible with the value requested if
    and only if the inequality "offered kind >= requested kind" evaluates
    to 'TRUE'. For the purposes of this inequality, the values of
    DESTINATION_ORDER kind are considered ordered such that
    BY_DESTINATION_TIMESTAMP < BY_SOURCE_TIMESTAMP.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-162 Separate_transient_into_two_kinds

  • Key: DDS-129
  • Legacy Issue Number: 6835
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The description of the DURABILITY Qos in section 2.1.3 is ambiguous
    with regards to the TRANSIENT kind. It would appear that there are in
    fact two kinds:

    The first interpretation "TRANSIENT_LOCAL" would have the durability
    tied to the liveliness of the DataWriter..

    The second interpretation "TRANSIENT_GLOBAL would tie the durability
    to the fact that some "durability servide" in the system is still
    executing.

    It should be explained which of these interpretations is meant.

    **PROPOSAL**

    Modify the QoS table in 2.1.3 to separate the TRANSIENT durability
    into two kinds: TRANSIENT_LOCAL and TRANSIENT.

    TRANSIENT_LOCAL ties the durability to the liveliness of the
    writer. This is the mandatory level described in Appendix A.

    TRANSIENT allows the durability to survive the liveliness of the
    DataWriter. Explain this kinds in the table and in section 2.1.3.2

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-144 Wrong_description_of_compatible_DURABILITY

  • Key: DDS-125
  • Legacy Issue Number: 6831
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    In Section 2.1.3, QoS table. Section on DURABILITY setting.

    Says compatible only if requested kind > offered kind. Should have
    said requested >= offered. Same in PRESENTATION

    **PROPOSAL**

    Replace "requested kind > offered kind" with "requested kind >=
    offered kind"

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-108 Ownership_interaction_with_deadline

  • Key: DDS-122
  • Legacy Issue Number: 6828
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    In case where the OWNERSHIP QoS is EXCLUSIVE, the specification
    describes that ownership is lost if the DataWriter loses its
    liveliness. However it does not describe whether it loses the
    ownership if it misses its deadline with regards to writing the
    instance.

    If this case is left unspecified the most natural interpretations
    would be that the DataWriter does indeed maintain ownership even when
    it is missing its deadlines. This seems undesirable.

    We do not want a DataWriter that has promised to write samples within
    a pre-stated deadline and fails that contract to retain ownership of
    an instance and by so doing starve prevent other writers from writing
    the instance and therefore starve the reader from data. The
    underlying goal is to make the system robust to faults that affect a
    single entity.

    **PROPOSAL**

    Modify section 2.1.3.6.2 (EXCLUSIVE kind) to reflect this. This
    affects several paragraphs:

      • First paragraph

    Replace: The owner is determined by selecting the DataWriter with the
    highest value of the strength that is currently "alive" as defined by
    the LIVELINESS QoS policy.

    With: The owner is determined by selecting the DataWriter with the
    highest value of the strength that is both "alive" as defined by the
    LIVELINESS QoS policy and has not violated its DEADLINE contract with
    regards to the data-instance.

      • First paragraph

    After "Ownership can therefore change as a result of (a) ..."

    Add a forth case (d) a deadline with regards to the instance that is
    missed by the DataWriter that owns the instance.

      • Fifth paragraph

    Modify "It is also required that the owner remains the same until
    there is a change in strength, liveliness, or a new DataWriter with
    higher strength modifies the instance."

    To: "It is also required that the owner remains the same until there
    is a change in strength or liveliness, the owner misses a deadline on
    the instance, or a new DataWriter with higher strength modifies the
    instance."

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-156 Clarify_TIME_BASED_FILTER

  • Key: DDS-120
  • Legacy Issue Number: 6826
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification does not state clearly whether the TIME_BASED_FILTER
    applies on a per-instance basis or for the whole topic.

    It should probably be per instance but it should be said explicitly.

    **PROPOSAL**

    Add the clarification to section 2.1.3.8. State that the filter
    applier per instence, that is, the reader is requested not to receive
    more than one sample per minimum_separation period for each instance

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-106 Desc_of_Inconsistent_topic_status::total_count_change

  • Key: DDS-121
  • Legacy Issue Number: 6827
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.4.1. The Table that describes the statuses and the meaning
    of the attributes has an incorrect description of the
    "total_count_change"

    Currently it talks about topic names, not counts

    **PROPOSAL**

    In section 2.1.4.1 replace the text "The type of the last topic
    discovered..."

    With: "The incremental number of inconsistent topics discovered since
    the last time the listener was called or the status was read"

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-111 Default_values_for_qos

  • Key: DDS-124
  • Legacy Issue Number: 6830
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The QoS table in section 2.1.3 specifies default values for some of
    the QoS. Others however are unspecified.

    To be consistent we should provide some default value for all
    QoS. Meaning if the user never specified the QoS (assuming the
    Topic_qos_as_default_for_datareader_or_datawriter_qos issue is
    resolved) then we should specify what the behavior should be

    **PROPOSAL**

    Complete the table in section 2.1.3 with the following values:

    USER_DATA: empty sequence (zero-sized)

    DURABILITY: VOLATILE

    PRESENTATION: access_scope=INSTANCE, coherent_access=FALSE,
    ordered_access=FALSE

    DEADLINE: (already specified)

    LATENCY_BUDGET: says "zero" but that is not really meaningful so
    perhaps INFINITE?

    OWNERSHIP: (already specified)

    OWNERSHIP_STRENGTH: zero

    LIVELINESS: (already specified)

    TIME_BASED_FILTER: (already specified)

    PARTITION: empty sequence (zero length)

    RELIABILITY: (already specified)

    DESTINATION_ORDER: BY_RECEPTION_TIMESTAMP

    HISTORY: (already specified)

    RESOURCE_LIMITS: (already specified)

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-104 Coupling_bwn_TIME_BASED_FILTER_and_RELIABILITY

  • Key: DDS-119
  • Legacy Issue Number: 6825
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.3 on the QoS table. The description of the
    TIME_BASED_FILTER QoS says"

    "The setting of this QoS is incompatible with RELIABILITY policy set
    to ALL"

    First there is no such setting for reliability policy. It intended to
    say it is incompatible with RELIABILITY 'RELIABLE' and HISTORY
    'KEEP_ALL'.

    However it is unclear why it is necessary introduce such
    incompatibility. It would be better to interpret the meaning of
    RELIABLE and KEEP_ALL to mean that the application desires that all
    samples that pass whichever filters have been specified are propagated
    reliably and kept by the middleware until they can be delivered to the
    DataReader. In other words, the RELIABILITY and HISTORY policies apply
    after the "filter-type" policies apply. The filters determine what is
    of interest, the reliability whether samples lost by the transport
    should be retried and the HISTORY whether to keep old values that have
    not been delivered to the application once a new value
    exist. Interpreted this way all combination of the above policies are
    sensical. This approach also extends to the ContentFilteredTopic

    **PROPOSAL**

    Remove that comment from the TIME_BASED_FILTER QoS

    Add a third paragraph to section 2.1.3.8 that explains that it is
    indeed possible to specify RELIABILITY RELIABLE, and a HISTORY
    KEEP_ALL and still set a TIME_BASED_FILTER. The paragraph would say:

    The setting of a TIME_BASED_FILTER, that is, the selection of a
    minimum_separation with a value greater than zero is compatible with
    all settings of the HISTORY and RELIABILITY QoS. The TIME_BASED_FILTER
    specifies the samples that are of interest to the DataReader. The
    HISTORY and RELIABILITY affect the behavior of the middleware with
    respect to the samples that have been determined to be of interest to
    the DataReader, that is, they apply after the TIME_BASED_FILTER has
    been applied.

    Specify that that if the reliability is RELIABLE then in steady-state
    it should behave as-if the last sample passes the
    TIME_BASED_FILTER. In other words, in steady state the last sample
    should eventually become available to the receiver.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-210 Clarification_of_responsibility_of_RxO_qos

  • Key: DDS-117
  • Legacy Issue Number: 6823
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    In section 2.1.3 the explanation of the table mentions: "The QosPolicy
    objects that need to be set in a compatible manner at the publisher
    end are indicated by the setting of the RxO property" This suggests an
    asymmetry between publishers and subscribers. It is not true that
    compatibility of policy objects is entirely the responsibility of the
    publisher, is it?

    **PROPOSAL**

    In said sentence replace "at the publisher end" with "between the
    publisher and subscriber ends".

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 34] Initial data when DataWriter appears

  • Key: DDS-114
  • Legacy Issue Number: 6820
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-90 Initial_data_from_transient_or_persistent_data

    The specification mentions that if the DURABILITY is set to TRANSIENT
    or PERSISTENT a newly appearing DataReader would be able to get some
    amount of history data.

    However the precise semantics of this are not clear. For example is
    the application allows to receive information as soon as the Reader is
    active (perhaps from active writers) even before the historical data
    has been received?

    It would be desirable to offer the application some control about how
    to initialize the reader when it first joins the system.

    **PROPOSAL**

    Introduce an operation DataReader:: get_historical_data(in Duration_t
    max_time_to_wait);

    This operation will block for a maximum of max_time_to_wait until the
    system gets the initial data.

    Introduce the ReturnCode_t "TIMEOUT" to section 2.1.1.1.

    State that the get_historical_data operation will return OK if all the
    initial data has been received. Otherwise it will return TIMEOUT if
    the system cannot ensure that all historical data has been received.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-212 Qos_Coupling_TimeBasedFilter_deadline

  • Key: DDS-118
  • Legacy Issue Number: 6824
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    In section 2.1.3.4 it is unclear whether the service is expected to
    check compatibilities between DEADLINE and TIME_BASED_FILTER
    policies. For example, a DataWriter offering a DEADLINE period smaller
    than a DataReaders TIME_BASED_FILTER is bound to lead to problems with
    reliable transmission.

    Another example is a DataReader which has a DEADLINE period smaller
    than the TIME_BASED_FILTER period.

    **PROPOSAL**

    State that DataReader which has a DEADLINE period smaller than the
    TIME_BASED_FILTER period results on INCONSISTENT_POLICY.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency on what operations may return NOT_ENABLED

  • Key: DDS-115
  • Legacy Issue Number: 6821
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-204 Entity_table_get_statuscondition_return_not_enabled

    Section 2.1.2.1.1, 1st paragraph under the Entity table: In the list
    of methods which cannot return a "NOT_ENABLED", the
    "get_statuscondition" method is not mentioned.

    This is inconsistent with the text in 2.1.2.1.1.7 where it says that
    get_statuscondition may be called even if the entity is not enabled.

    **PROPOSAL**

    Remove the sentence 2.1.2.1.1, 1st paragraph "All operation except for
    ... return the value NOT_ENABLED" as this is already described in
    2.1.2.1.1.7

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 31] Topic QoS refactor

  • Key: DDS-111
  • Legacy Issue Number: 6817
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-86 Topic_qos_refactor and Ref-150
    Tracking_of_topic_properties_by_reader_writer

    The reason for the DDS specification to add QoS to the Topic was to
    allow annotating the information-model with Topic QoS settings. That
    way it is possible for the individual applications and their designers
    to be relieved from many details and configure the writers/readers
    from this information model.

    However the definition of the Topic QoS does not match this.

    Section 2.1.2.4.3.2 describes a model where if the QoS is 'not set' on
    a dataWriter or a DataReader, then the one of the Topic is used
    instead. Furthermore it says that in this situation the QoS of the
    Entity will "track" that of the Topic.

    These statements are not consistent with the PIM or PSM as there is no
    way provided to 'not set' a QoS. All the API's force complete setting
    of the QoS.

    Furthermore the 'tracking' behavior would be very hard to implement
    and it would also be very confusing for an user that has a QoS of an
    entity magically change when the QoS of the topic changes. Lastly it
    would also be hard to handle the case where as a result of the
    'tracking' the QoS of an entity becomes incompatible with that of
    other entities already associated with it.

    Given all this it would be desirable to make the use of Topic QoS
    consistent with the API's and also simpler to implement and understand

    **PROPOSAL**

    Modify section 2.1.2.4.3.2.

    Remove all references to behaviors regarding what happens if some QoS
    is "not set" rather say that QoS is always explicitly set although it
    can be set from defaults in the factories.

    Also remove the sentence regarding how the entity QoS can "track" the
    Topic qos.

    Explain that the pattern to create an entity with "default" QoS is to
    get the default qos from the factory, and also get it from the Topic,
    and then modify the desired policies before creating the entity.

    To assist this common pattern we recommend adding the following
    utility operations:

    Publisher::initialize_from_topic_qos(inout DataReaderQos qos, in Topic
    a_topic, in long mask)

    Subscriber::initialize_from_topic_qos(inout DataWriterQos qos, in
    Topic a_topic, in long mask)

    Specify that all QoS on Topic is immutable.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 36] QoS clarifications

  • Key: DDS-116
  • Legacy Issue Number: 6822
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-208 Latency_budget_description

    Section 2.1.3 has a wrong description of LATENCY BUDGET. It says that
    it specifies the acceptable delay from production time until 'it is
    received by subscribing application' which might suggest that it
    includes the time an application might wait until actually reading the
    data.

    Rather it should say that it specifies the acceptable delay from
    production time until the data is inserted in application-cache and
    the application is notified of the fact.

    **PROPOSAL**

    Update the description. In the table to say that "it specifies the
    acceptable delay from production time until the data is inserted in
    application-cache and the application is notified of the fact"

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 33] Initialization of resources needed

  • Key: DDS-113
  • Legacy Issue Number: 6819
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    ] Initialization of resources needed to implement
    DURABILITY TRANSIENT or PERSISTENT

    ***Ref-91 Configuration_of_the_transient_and_persistent_service

    The DDS specification does not provide a clear model of the behavior
    of the service when the DURABILITY QoS is set to TRANSIENT or
    PERSISTENT

    Moreover for the application needs to be able to specify the QoS
    parameters and resources that the implementation is allowed to use
    when implementing this service.

    **PROPOSAL**

    Add the following explanation to section 2.1.3.2:

    For the purpose of implementing the the DURABILITY QoS settings of
    TRANSIENT, PERSISTENT the service behaves "as if" it had a "built-in
    DataReader and DataWriter" for each Topic that is configured to have
    said DURABILITY kind. In other words, it is "as if" somewhere in the
    system (possibly on a remote node) there was a "built-in durability"
    DataReader that subscribed to that Topic and a "built-in durability"
    DataWriter that published that Topic as needed for the new subscribers
    that join the system.

    For each Topic, the built-in "persistence service"
    datareader/datawriter has its QoS configured from the Topic QoS for
    that Topic as described in Issue Topic_qos_refactor (Issue #86). In
    otherwords, it is as-if the service first did a
    "Participant::lookup_topic" for that Topic, and then used the QoS on
    the Topic to configure the built-in entities.

    As a consequence of this model, the transient or persistence serviced
    can be configured by means of setting the proper QoS on the Topic.

    For a given Topic, the usual request/offered semantics apply to the
    matching between any DataWriter in the system that writes the Topic
    and the built-in transient/persistent DataReader for that
    Topic. Similarly for the builtin transient/persistent DataWriter for
    the Topic and any DataReader for the Topic. As a consequence, a
    DataWriter that has an incompatible QoS with respect to what the Topic
    specified for the built-in transient/persistent DataReader will not
    send its data to the transient/persistent service, and a DataReader
    that has incompatible QoS with respect to the specified in the Topic
    for the transient/persistent DataWriter will not get data from it.

    Incompatibilities between local DataReader/DataWriter entities and the
    corresponding builtin transient/persistent entities cause the
    "incompatible qos" listener to be invoked as they would with any other
    entity.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 32] Create dependencies on type

  • Key: DDS-112
  • Legacy Issue Number: 6818
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-89 State_dependency_register_type_create_datareader_writer

    The specification does not say clearly whether a TopicDescription can
    be created if the associated type has not been registered and what
    happens if the user tries to do that.

    **PROPOSAL**

    State explicitly that the operations that create specializations of
    TopicDescription, that is, create_topic and create_multitopic and
    lookup_topic, Will return PRECONDITION_NOT_MET if type not locally
    registered

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 30] Setting of default qos on factories

  • Key: DDS-110
  • Legacy Issue Number: 6816
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-?? Setting_default_qos_on_factories

    The specification provides a way to create Entities with QoS by
    explicitly providing the QoS when the entity is created.

    In some cases it would be desirable to provide a pattern such that
    many entities can be easily created with the same QoS without the
    application explicitly. Thst way the management of the Qos can be
    "centralized" in few modules in the application logic

    **PROPOSAL**

    Add the following operations:

    DomainParticipant::set_default_publisher_qos(),
    DomainParticipant::get_default_publisher_qos(),
    DomainParticipant::set_default_subscriber_qos(),
    DomainParticipant::get_default_subscriber_qos(),
    Publisher::set_default_datawriter_qos(),
    Publisher::get_default_datawriter_qos(),
    Subscriber::set_default_datawriter_qos(),
    Subscriber::get_default_datawriter_qos().

    This allows the application to set a default QoS for the entities that
    the factory will create, and then explicitly use that QoS to create
    the entities.

    Furthermore specify that if the set_default_xxx_qos operations are not
    called then the get_default_xxx_qos will return the defaults specified
    in section 2.1.3

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

[DDS ISSUE# 28] Desirability to define "information model" in a file

  • Key: DDS-108
  • Legacy Issue Number: 6814
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-77 Offering_the_possibility_to_define_topics_in_a_file _

    It would be desirable to have an "information model" where the QoS of
    the topics is specified in some file.

    This information model would also contain the QoS for the Topic.

    **PROPOSAL**

    No action as this seems beyond what the FTF could solve.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    No action as this seems beyond what the FTF could solve

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 26] Definition of DCPSKey

  • Key: DDS-106
  • Legacy Issue Number: 6812
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-68 Definition_of_DCPSKey

    Section 2.1.5. This section introduces a type DCPSKey, this type is
    not specified anywhere.

    This key however is only used for the built-in types so it would be
    better if, to avoid confusion, is named BuiltinTopicKey_t

    **PROPOSAL**

    Rename DCPSKey to be BuiltinTopicKey_t

    Define it in the IDL PSM the same way IntanceHandle_t is defined so
    that each vendor can define it as needed.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 29] Disposing a multi-topic

  • Key: DDS-109
  • Legacy Issue Number: 6815
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-83 Multitopic_refactor _

    The specification does not say when a MultiTopic is disposed

    **PROPOSAL**

    State in section 2.1.2.3.4 that MultiTopic will dispose as soon as one
    of the underlying Topic that are its components is disposed

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 27] Additional situations resulting in inconsistent QoS

  • Key: DDS-107
  • Legacy Issue Number: 6813
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-73 Depth_must_be_less_or_equal_ max_samples_per_instance

    Clarify that depth <= max_samples_per_instance otherwise its an
    inconsistent QoS

    **PROPOSAL**

    State this requirement in 2.1.3.12 and 2.1.2.13

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 24] Clarification of status flag

  • Key: DDS-104
  • Legacy Issue Number: 6810
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-64 Association_of_status_and_statuschangedflag

    Why does every status have an associated object "StatusChangedFlag"
    instead of a boolean attribute "changed"?

    Figure 2-14 (2.1.4.2) is at least misleading and should be clarified
    regarding this point. It suggests a 1 to n relation with a
    "StatusChangedFlag" class.

    Even though the diagram was only meant as conceptual explanation, not
    for providing an implementation architecture it would be desirable to
    improve specification in this respect.

    **PROPOSAL**

    Add text to 2.1.4.2 to explain that this figure is conceptual and
    simply represents that the Entity knows which specific statuses have
    changed, it does not imply a particular implementation in terms of
    Boolean flags.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-134 Additional_w_timestamp_operations

  • Key: DDS-101
  • Legacy Issue Number: 6807
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    It seems that the samples that indicate the 'disposing' of an instance
    need to also be sorted with respect to other samples and the sorting
    should follow DESTINATION_ORDER policy

    However if DESTINATION_ORDER is BY_SOURCE_TIMESTAMP and the
    application is explicitly passing the timestamp to write_w_timestamp
    there is no way to also specify the time when an instance is disposed

    The same applies to unregister. It may be necessary to order it with
    respect to other events

    **PROPOSAL**

    Add a dispose_w_timestamp operation to DataWriter.

    Add an unregister_w_timestamp operation to DataWriter

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 25] Addition of read and take to ReadCondition

  • Key: DDS-105
  • Legacy Issue Number: 6811
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-60 Adding_read_take_to_ReadCondition

    Why not have a read and take operation on readcondition instread of
    read_w_condition and take_w_condition?

    In the current situation the middleware must perform consistency
    checking and handle error conditions.

    Moving the read and take to the readCondition will require generation
    of typed interfaces but this is merely a wrapper around the current
    situation avoiding the error prone design.

    For example, if a Waitset has many query conditions. Then the
    application would need to find the reader that matches it. Adding a
    get_reader in the querycondition would not give a strongly-typed
    reader.

    The simplest solution is to have a read in the querycondition.

    **PROPOSAL**

    create the ReadCondition and QueryReadCondition as implied IDL

    We will move create_readcondition to the FooDataReader

    Add a read to the Read and QueryConditions

    Remove the read_w_condition from the DataReader and FooDataReader

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ISSUE# 23] Make Listener inheritance explicit in figures 2-9 and 2-10

  • Key: DDS-103
  • Legacy Issue Number: 6809
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-51Forward_mention_PublisherListener_inheritance and Ref-61
    Forward_reference_SubscriberListener_baseclass

    In 2.1.2.4 the PublisherListener interface extends the
    DataWriterListener, this is not mentioned until 2.1.4.3 after
    PulisherListener has been described

    The same applies to 2.1.2.5 with SubscriberListener and
    dataReaderListener

    **PROPOSAL**

    Modify figures 2-9 and 2-10 to show this relationships. Or at least
    mention them in section 2.1.2.4.3 and 2.1.2.5.6

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 22] Details in the code generation

  • Key: DDS-102
  • Legacy Issue Number: 6808
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-47 Details_on_type_specific_code_generation

    Section 2.1.2.3.7 says "It is required that each implementation of the
    Service provides an automatic means to generate this type-specific
    class from a description of the type (using IDL for example in the
    CORBA mapping)."

    The details of this generation for the CORBA mapping should be
    mentioned in the CORBA PSM (Section 2.2).

    **PROPOSAL**

    Add to section 2.1.2.3.7 the clarification that IDL should be used for
    the language and perhaps also a figure similar to Figure 3-3 in
    section 3.1.4.5 (in the DLRL) showing the process with potential
    vendor-specific file for keys or QoS

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 21] Helper operations

  • Key: DDS-100
  • Legacy Issue Number: 6806
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-32 Quering_waitset_for_attached_conditions

    The WaitSet class has methods for attaching and detaching conditions
    to it, but no method for querying which conditions are attached.

    **PROPOSAL**

    In section 2.1.2.1.6 add a get_conditions method that returns a
    ReturnCode_t and has a collection of conditions as an out
    paramater. In section 2.2.3 (IDL) add the corresponding operation.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 20] Narrow the applicability of assert liveliness

  • Key: DDS-99
  • Legacy Issue Number: 6805
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-29 Entity_operation_assert_livelines

    Class Entity has a function assert_liveliness, which is inherited by
    all derived classes. However, this function is relevant in combination
    with the LIVELINESS QoS policy only, and has only defined behavior on
    DomainParticipant and DataWriter

    **PROPOSAL** Remove assert_liveliness from Entity and introduce it
    in DataWriter and Participant

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 17] Clarify consequence of changing partitions

  • Key: DDS-96
  • Legacy Issue Number: 6802
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-17 PartitionQos_behavior_on_change

    The specification does not make it clear whether changing the
    PARTITION QoS on a Publisher or Subscriber affects the existing
    DataReader or DataWriter establishing some "associations" that did not
    exist before, or breaking associations that existed.

    Furthermore the specification does not describe whether the
    INCOMPATIBLE_QOS listeners/ status will be triggered

    Given that partitions are intended to be used to separate logically
    separate 'communication words' so that you can isolate things it would
    seem that changing partitions should affect existing DataReader and
    writers and not trigger the INCOMPATIBLE_QOS.

    **PROPOSAL**

    Modify section 2.1.3.9 to clarify that (1) changing the PARTITION QoS
    on a Publisher or Subscriber does affect the existing DataReader or
    DataWriter entities. It may establish new "associations" that did not
    exist before, or break existing associations.

    Also explain in section 2.1.3.9 that not matching the PARTITION QoS
    does not trigger the INCOMPATIBLE_QOS listener nor change the
    associated status.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 19] Initial value of entity status changes

  • Key: DDS-98
  • Legacy Issue Number: 6804
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-26 Initial_value_of_entity_status

    The specification does not define the initial value of the status of
    an entity after initializations/enabling

    **PROPOSAL**

    Specify in section 2.1.2.1.1.6 that when the entity is created the
    return of get_status_changes is an empty mask indicating that no
    status have changed

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 16] Clarification of expression syntax

  • Key: DDS-95
  • Legacy Issue Number: 6801
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-14 Relationship_of_IDL_and_expression_syntax

    The fieldnames and topicnames used in SQL expressions need to be
    language-independent. This means that they have to be derived from the
    IDL-definition. The SQL description in Annex A/B does not define the
    relationship between the FIELDNAME and the IDL definition.

    Example, assume the following IDL definition:

    module mymodule { struct mystruct

    { long record; }

    ; };

    The SQL statement could become "SELECT record AS value FROM
    mymodule.mystruct ...".

    The field "record" would be translated into "IDL_record" by an ADA
    preprocessor. The SQL-statement should still use "record" to be
    language independent. This is a generic situation that occurs for each
    language when the name of the field matches a reserved keyword.

    **PROPOSAL**

    Improve specification "Annex A/B" stating that the syntax of the SQL
    statement will match the names used in IDL not necessarily those of
    the language mapping.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Behavior on creation failure

  • Key: DDS-97
  • Legacy Issue Number: 6803
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-21 Error_status_on_create_calls

    The specification does not explain the return value of the factory
    "create" calls if the operation fails, for example due to inconsistent
    QoS.

    **PROPOSAL**

    Add text that explains that in case of failure the return value is NIL
    (as defined on each PSM).

    This affects 2.1.2.2.2.1, 2.1.2.2.1.1, 2.1.2.2.1.5, 2.1.2.2.1.7,
    2.1.2.2.1.9, 2.1.2.4.1.5, 2.1.2.5.2.5

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 15] Semantics of register and unregister instance

  • Key: DDS-94
  • Legacy Issue Number: 6800
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-13 Semantics_of_register_unregister_instance

    The semantics of the register_instance and unregister_instance methods
    are not entirely clear. From section 2.1.2.5.1 it seems that both
    methods have, apart from their local memory management purpose on the
    Publisher side, also a purpose with respect to determining the
    LIVELINESS of a DataWriter on the Subscriber side. This means that
    these methods will probably result in network communication as well

    **PROPOSAL**

    Clarify the semantics by adding the following paragraphs as needed to
    sections 2.1.2.5 and to 2.1.3:

    The need for registering/unregistering instances stems from two use
    cases: (1) Ownership resolution on redundant systems, and (2)
    Detection of loss in topological connectivity and the consequent
    difference in the semantics of unregister and dispose (3).

    (1) Ownership resolution on redundant systems

    It is expected that users will use DDS to set up redundant systems
    where multiple DataWriters are "capable" of writing the same
    instance. The data-writers are either configured such that both are
    writing the instance "constantly" or else they use some mechanism to
    monitor each other and only write when they detect that the primary
    "writer" is no longer writing.

    Either of the above two cases uses the OWNERSHIP policy "Exclusive"
    and arbitrate themselves by means of the OWNERSHIP_STRENGTH. The
    desired behavior is that when the "primary" writer stops writing, the
    application should start to receive data from the secondary subscriber

    This approach requires some mechanism to detect that the "writer" is
    no longer "writing" the data as it should. There are several reasons
    why this may be happening and all must be detected (but not
    necessarily distinguished):

    The writing process is no longer running (e.g. the whole application
    has crashed)

    Connectivity to the writing application has been lost (e.g. network
    got disconnected)

    Application logic that was writing the data is faulty and has stopped
    doing so.

    Arbitrating from a writer to one of a higher strength is simple and
    the decision can be taken autonomously by the reader. Switching
    ownership from a higher strength writer to one of a lower strength
    requires that the "reader" application can make a determination that
    the "writer" application is "no longer writing the instance".

    (1.1) Case where the data is periodically updated

    This determination is reasonably simple when the data is being written
    periodically at some rate. The writer simply states its offered
    deadline (maximum interval between updates) and the reader monitors
    that the writer indeed updates the instance at least once per
    deadline_period. If the deadline is missed, the reader considers the
    writer "not alive" and gives ownership to the highest-strength writer
    that is alive

    (1.2) Case where data is not periodically updated

    The case where the writer is not writing data periodically is also a
    very important use-case. Since the data is not being updated at any
    fixed period, the "deadline" mechanism cannot be used to determine
    ownership. The liveliness neatly solves this situation. Ownership is
    maintained while the writer is "alive" and for the writer to be alive
    it must be fulfill its "LIVELINESS" contract. The different means to
    renew liveliness (automatic, manual) combined by the implied renewal
    each time data is written handle the three conditions above (a), (b),
    or (c) ( note that to handle (c) Liveliness must be
    MANUAL_BY_TOPIC). Now the writer can retain ownership by periodically
    writing data or else calling assert_liveliness() if it has no data to
    write. Alternatively if only protection against (a) or (b) is desired,
    it is sufficient that some task on the writer process periodically
    writes data or calls assert_liveliness() on the participant.

    However, this scenario requires that the reader knows what instances
    are being "written" by the writer. That is the only way that the
    reader can maintain ownership of specific instances from the fact that
    the writer is still "alive". Hence the need for the writer to
    "register" and "unregister" instances. Note that while "registration"
    can be done lazily the first time the writer writes the instance,
    "unregistration" in general cannot. Unless we are willing to say that
    once a writer writes an instance it will forever write the instance
    until the writer is deleted. Similar reasoning will lead to the fact
    that unregistration will also require a message to be sent to the
    readers

    (2) Detection of loss in topological connectivity

    There are applications that are designed in such way that their
    correct operation requires some minimal topological connectivity, that
    is, the writer needs to have a minimum number or readers or
    alternatively the reader must have a minimum number of writers.

    A common scenario is that the application does not start doing is
    logic until it knows that some specific writers have the minimum
    configured readers (e.g the alarm monitor is up).

    A more common scenario is that the application logic will wait until
    some writers appear that can provide some needed source of information
    (e.g. the raw sensor data that must be processed).

    Furthermore once the application is running it is a requirement that
    this minimal connectivity (from the source of the data) is monitored
    and the application informed if it is ever lost. For the case where
    data is being written periodically, the DEADLINE QoS and the
    on_deadline_missed() listener provides the notification. The case
    where data is not periodically updated requires the use of the
    LIVELINESS in combination with register/unregister instance to detect
    whether the "connectivity" has been lost, and the notification is
    provided by means of the "NO_WRITERS" lifecycle state.

    In term of the required mechanisms the scenario is very similar to the
    case of maintaining ownership. In both cases the reader needs to know
    whether a writer is still "managing the current value of an instance"
    even though it is not continually writing it and this knowledge
    requires the writer to keep its liveliness plus some means to know
    which instances the writer is currently "managing" (i.e. the
    registered instances).

    Note that the need to notify the reader that a particular instance has
    no writers does not imply that the mechanism is the use of a
    "NO_WRITES" lifecycle. We could just as well use a listener. The
    listener mechanism has the problem that there is no way to know which
    instances are the ones that have no writers. But this is also a
    problem for the "on_deadline_missed" listener so we think it would be
    a good idea to refractor these two mechanisms to that they are similar
    in nature and both provide the means to determine which instances have
    the problem.

    (3) Difference between unregister and dispose

    Dispose is different than unregister. The "dispose" indicates that the
    data-instance no longer exists (e.g. a track that has disappeared, a
    simulation entity that has been destroyed, a record entry that has
    been deleted, etc.) whereas the "unregister" indicates that the writer
    is no longer taking responsibility for updating the value of the
    instance.

    Deleting a data-writer is equivalent to unregistering all the
    instances it was writing, but is not the same as "disposing" all the
    instances.

    For a topic with EXCLUSIVE ownership if the current owner of an
    instance disposes it, the readers an instance will see the lifecycle
    as being "DELETED" and not see the values being written by the weaker
    writer (even after the stronger one has disposed the instance). This
    is because the owner of the instance is saying that the instance no
    longer exists (e.g. the master of the database is saying that a record
    has been deleted) and thus the readers should see it as such.

    For a topic with EXCLUSIVE ownership if the current owner of an
    instance unregisters it than it will relinquish ownership and thus the
    readers will see the value updated by another writer (which will then
    become the owner). This is because the owner said that it no longer
    will be providing values for the instance and thus any other writer
    can take ownership and provide those values

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-118 Introduce_TIME_INVALID_constant

  • Key: DDS-92
  • Legacy Issue Number: 6798
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The PSM/IDL does not provide the means for an application to specify
    an invalid time (e.g. in the SampleInfo)

    **PROPOSAL**

    Add the following constant to the IDL:

    Timestamp t TIMESTAMP_INVALID =

    { -1, 0 }
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-102 Addition_of time_related_constants

  • Key: DDS-93
  • Legacy Issue Number: 6799
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Sometimes it is necessary to represent a zero duration as well as an
    invalid time.

    A zero duration is needed for example to provide the value of a
    minimum_separation when a TIME_BASED_FILTER is not desired.

    An invalid time is needed when samples are returned that do not
    represent actual data.

    The representation of a DURATION_ZERO clearly is a Time_t with values

    {0, 0}

    . However it is desirable that the name of this constant is
    standardized across implementations.

    **PROPOSAL**

    Add the following constant to the IDL:

    Timestamp t DURATION_ZERO =

    { 0, 0 }
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 14] Helper addition to the IDL

  • Key: DDS-91
  • Legacy Issue Number: 6797
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-33 Specification_of_infinite_duration

    The PSM/IDL does not provide the means for an application to specify
    an infinite duration (e.g as a timeout)

    **PROPOSAL**

    Add the following constant to the IDL:

    Duration_t DURATION_INFINITE =

    { 0x7ffffff, 0xffffffff }
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of Topic versus TopicDescription

  • Key: DDS-87
  • Legacy Issue Number: 6793
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-43 TopicDescription _name_attribute

    In section 2.1.2.3 TopicDescription has an attribute called "name.
    However the IDL is inconsistent. TopicDescription does not have the
    "name" attribute, instead Topic has the name and the other derived
    classes (ContentFilteredTopic and MultiTopic) do not have a name

    In the IDL specification the name specified by the TopicDescription
    but instead only by the Topic.

    It makes sense to have the name on TopicDescription as in the PIM such
    that all kinds of TopicDescription entities can be locally accessed by
    means of "lookup_topic".

    **PROPOSAL**

    Fix the PIM IDL file to match the PSM.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-31 Reason_and_use_of_enabled

  • Key: DDS-90
  • Legacy Issue Number: 6796
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The "enable"operation was added in support of DLRL. However if the
    application is not using DLRL it is often inconvenient to have to
    explicitly "enable" each entity before using it.

    **PROPOSAL**

    Add a QoS to the DomainParticipant, Publisher and Subscriber called
    ENTITY_CREATION_SETTINGS. This QoS contains the Boolean
    "create_enabled". If this Boolean is set to "TRUE" then the entities
    created by the factory will be automatically enabled (i.e. the factory
    will call the enable() before returning the entity).

    Specify that the default value of this setting is TRUE.

    Specify that this QoS is mutable

    This affects sections 2.1.3, and 2.2.3

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reason and use of enable

  • Key: DDS-89
  • Legacy Issue Number: 6795
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-30 Topic_enable_semantics

    In section 2.1.2.1.1.7 it is not clear what is the precise semantics
    of the "enable" on a Topic are? Can the same or another node see it
    (by means of "lookup_topic") a Topic that has not been enabled?

    Similarly can the TopicListener be invoked before the Topic is
    enabled. It appear undesirable since the QoS may still change.

    **PROPOSAL**

    Clarify that the Topic is not accessible by means of "lookup" neither
    locally not globally until it has been enabled.

    Also clarify that the TopicListener will only be called after the
    Topic is enabled.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-40 Name_and_return_type_of_lookup_topic

  • Key: DDS-88
  • Legacy Issue Number: 6794
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Currently, the lookup_topic method returns a type Topic. Why does it
    not return a type TopicDescription? In that case, it could also be
    used to search for ContentFilteredTopics and MultiTopics.

    **PROPOSAL**

    Change prototype lookup_topic to return TopicDescription.

    Change name from lookup_topic to lookup_topicdescription

    Specify that lookup_topicdescription will also find
    ContentFilteredTopic and MultiTopic

    This affects sections 2.1.2.2.1.11, and 2.2.3.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Duplicate use of domainId

  • Key: DDS-86
  • Legacy Issue Number: 6792
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-38 Duplicate_domainId_to_create_participant

    The specification does not clarify the behavior of
    DomainParticipantFactory create_participant when the domainId
    specified is already used.

    **PROPOSAL**

    Return a HANDLE_NIL in that case.

    Also add a lookup_participant method to DomainParticipantFactory with
    a parameter of type DomainId_t. to allow finding a pre-exising
    DomainParticipant.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-02 Data_Available_status_transition

  • Key: DDS-85
  • Legacy Issue Number: 6791
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The data available status becomes TRUE when data is available, but
    under what condition does it become FALSE again?

    According the specification when data is taken, but does this only
    apply to the object that is accessed? Or do the status values of other
    objects that become untrue as a result of the take action also need to
    be changed?

    Example: A reader with 3 queries, data arrives and the status of the
    reader and all queries become TRUE. The data is taken via the reader,
    do the status values of the queries become FALSE?

    **PROPOSAL**

    Add the following clarifications to section 2.1.4.4

    DataReader::take() and DataReader::read() changes the status of the
    queries that are no longer true after the 'take'. Since 'take' removes
    the data from the service so its no longer there it would make little
    sense for the status to remain enabled.

    In other words the same way that arrival of data may change the 'data
    available status' of any query, so would the 'taking' or 'reading' of
    data potentially affect all queries.

    Note that this does not mean that waitesets that were attached to the
    query will not be woken up. This is an implementation issue. Once the
    query status changes to 'enabled' it may wake up the attached waitset,
    transitioning to 'not-enabled' does not necessarily 'unwakeup' the
    waitset since this operation is in general not possible. The
    consequence is that the application may be woken up and not see any
    active conditions. This is unavoidable if multiple threads are
    concurrently taking data.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-229 IDL_rename_publisher_laxity_w_latency_budget

  • Key: DDS-83
  • Legacy Issue Number: 6789
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.2.3 IDL. TopicQos, DataWriterQos, DataReaderQos have field
    called delay_laxity should be latency_budget according to the PIM

    **PROPOSAL**

    Change the IDL to match the PIM by renaming delay_laxity to
    latency_budget

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-63 QoS_USER_DATA_on_Publisher_and_Subscriber

  • Key: DDS-82
  • Legacy Issue Number: 6788
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.3. According to the QosPolicy table, USER_DATA does not
    concern Publisher and Subscriber entities. The IDL PSM however has
    UserDataQosPolicy as a member of both the PublisherQos and
    SubscriberQos structures.

    **PROPOSAL**

    Correct the PSM. USER_DATA remove USER_DATA from Publisher and
    Subscriber

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification of listener invocation and waitset signaling

  • Key: DDS-84
  • Legacy Issue Number: 6790
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-01 Listener_waitset_triggering

    The specification does not make clear whether listeners and waitsets
    are awaken once per "event" that causes a change of status (implying a
    queue of events) or are they just awaken once when the status changes.

    **PROPOSAL**

    Clarify that there is no implied "queueing". The listeners and
    waitsets are enabled based on the status change but not necessarily
    called/signaled multiple times. This clarification should appear in
    section 2.1.4.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-135 Missing_accessor_for_SampleRejectedStatus

  • Key: DDS-81
  • Legacy Issue Number: 6787
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Attribute/accessor for SampleRejectedStatus missing from 2.1.2.5.3

    **PROPOSAL**

    Add the get_xxx accesor to the DataReader class

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-126 Inconsistent_parameter_order_to_get_datareaders

  • Key: DDS-80
  • Legacy Issue Number: 6786
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    In section 2.1.2.5.2 the order of parameters in get_datareaders is
    (LifecycleState, SampleState) is inconsistent with the order in the
    methods which is (SampleState, LifecycleState)

    **PROPOSAL**

    Change parameter order to (SampleState, LifecycleState) This affects
    both the PIM (section 2.1.2.5.2) and the IDL PSM

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-59 FooDataReader_read_take_parameter_order

  • Key: DDS-75
  • Legacy Issue Number: 6781
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.2.5.3 FooDataReader class table, operation read and
    take. In the table, lifecycle_states and sample_states parameters are
    reversed with respect to IDL PSM.

    **PROPOSAL**

    Correct section 2.1.2.5.3.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-70 Missing_deadline_statuskind_from_pim

  • Key: DDS-76
  • Legacy Issue Number: 6782
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.2.2. The PSM IDL StatusKind constant definitions
    OFFERED_INSTANCE_DEADLINE_MISSED_STATUS and
    REQUESTED_INSTANCE_DEADLINE_MISSED_STATUS are not mentioned in the PIM
    and do not have a corresponding Status class either.

    **PROPOSAL**

    Correct PIM and add said statuses to section 2.1.4.1.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-205 On_requested_deadline_missed_paramtype

  • Key: DDS-79
  • Legacy Issue Number: 6785
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    2.1.2.2.3: In the "on_requested_deadline_missed" method, the second
    parameter is of type "RequestedIncompatibleQosStatus" instead of type
    "RequestedDeadlineMissedStatus"

    **PROPOSAL**

    Fix section 2.1.2.2.3. parameter type should be
    RequestedDeadlineMissedStatus

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-58 DataReader_read_take_w_condition

  • Key: DDS-74
  • Legacy Issue Number: 6780
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.2.5.3 (DataReader and FooDataReader class table),
    operations read_w_condition and take_w_condition. In the IDL file, the
    sample_info parameter is of type SampleInfo instead of SampleInfoSeq.

    **PROPOSAL** Correct the IDL PSM. sample_info parameter should be of
    type SampleInfoSeq.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-56 Subscriber_notify_datareaders_parameters

  • Key: DDS-73
  • Legacy Issue Number: 6779
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    In section 2.1.2.5.2, subscriber class table, operation
    notify_datareaders void. In the IDL file this method has two
    parameters: LifecycleStateMask and SampleStateMask

    **PROPOSAL**

    Correct the IDL PSM. Remove the parameters in the IDL file.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-57 FooDataReader_get_key

  • Key: DDS-72
  • Legacy Issue Number: 6778
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.2.5.3. FooDataReader class table. The get_key_value
    method is named get_key in the IDL PSM.

    **PROPOSAL**

    Correct the IDL PSM. Method should be named get_key_value

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-49 DataWriter_get_key

  • Key: DDS-71
  • Legacy Issue Number: 6777
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.2.4.2. DataWriter class table. The get_key_value method
    is named get_key in the IDL PSM.

    **PROPOSAL**

    Correct the IDL PSM. Method should be named get_key_value

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-88 Inconsistent_naming_PIM_IDL_instance_samples

  • Key: DDS-78
  • Legacy Issue Number: 6784
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Page 2-68 the field in QoS RESOURCE_LIMITS is called
    max_instance_samples. In the IDL (page 2-104) says
    max_samples_per_instance

    **PROPOSAL**

    Change table in 2-68 replace the two references to
    max_samples_per_instance

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-79 Missing_StatusKind_liveliness_idl_constants

  • Key: DDS-77
  • Legacy Issue Number: 6783
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The communication statuses LIVELINESS_LOST and LIVELINESS_CHANGED do
    not have a corresponding PSM IDL StatusKind constant definitions

    **PROPOSAL**

    Correct the IDL PSM. Add said definitions consistently with PIM.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-48 FooDataWriter_unregister_instance

  • Key: DDS-70
  • Legacy Issue Number: 6776
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.2.4.2. FooDataWriter class table. The unregister_instance
    method is specified to return InstanceHandle_t.

    The return type should be ReturnCode_t conform the IDL PSM.

    **PROPOSAL**

    Correct section 2.1.2.4.2 to match the IDL file.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-28 IDL_entity_get_statuscondition

  • Key: DDS-65
  • Legacy Issue Number: 6771
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.2.1.1. Method get_statuscondition. According to the IDL
    file, this method is replaced by two other methods named
    create_statuscondition and delete_statuscondition. Which of the two is
    right?

    The IDL is incorrect. Given that there is a single statuscondition
    associated with an Entity having only a get_statuscondition operation
    and no delete_statuscondition.

    **PROPOSAL**

    Correct the IDL. Replace the create_statuscondition and
    delete_statuscondition in the IDL with get_statuscondition as
    desxribed in the PIM.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-46 ContentFilteredTopic_related_topic

  • Key: DDS-69
  • Legacy Issue Number: 6775
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.2.3.3 in the ContentFilteredTopic class table, there is
    the attribute related_topic. This attribute is missing in the IDL PSM.

    **PROPOSAL**

    Correct the IDL to match the PIM.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-37 Entity_ specialization_set_get_listener_in_idl

  • Key: DDS-67
  • Legacy Issue Number: 6773
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    In section 2.2.3 (IDL) the entities DomainParticipant, Topic,
    Publisher, DataWriter, Subscriber, and DataReader are missing the
    get_listener/set_listener operations.

    Those operation are all present in the PIM.

    **PROPOSAL**

    Add said operations to the IDL to match the PIM

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-34 Incorrect_guard_condition_enabled_statuses

  • Key: DDS-66
  • Legacy Issue Number: 6772
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.2.1.8. The enabled_statuses attribute for a GuardCondition
    is incorrect since a GuardCondition does not have any relationship
    with status conditions.

    **PROPOSAL**

    Remove the attribute from section 2.1.2.1.8

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-42 DomainParticipantListener_on_requested

  • Key: DDS-68
  • Legacy Issue Number: 6774
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.2.2.3. DomainParticipantListener Interface table: The
    operation on_requested_deadline_missed_qos is mentioned instead of
    on_requested_deadline_missed.

    **PROPOSAL**

    Correct section 2.1.2.2.3

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-39 Entity_specialization_set_get_qos

  • Key: DDS-64
  • Legacy Issue Number: 6770
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.2.2.1. DomainParticipant class table defines an operation
    called delete_contentfilteredtopic. This operation is named
    inconsistently in the IDL PSM (section 2.2.3) where it appears as
    delete_contentfiltered in the IDL PSM.

    **PROPOSAL**

    Change the name of the operation in the IDL to
    delete_contentfilteredtopic.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistencies between PIM and PSM/IDL

  • Key: DDS-63
  • Legacy Issue Number: 6769
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    ***Ref-38 DomainParticipant_domainId

    Section 2.1.2.2.1. DomainParticipant class table. The attribute
    domainId is not mentioned although mentioned in the IDL PSM.

    **PROPOSAL**

    Correct PIM.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Entity specialization of set/get qos/listener

  • Key: DDS-61
  • Legacy Issue Number: 6767
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-35 Entity_specialization_set_get_qos

    The specification shows this operation as being abstract on the
    base-class (Entity) and says that it will be overridden by each
    specialization (Section 2.1.2.1.1.2). This is consistent with the PSM.

    However, the get_qos/set_qos operations are not mentioned in the
    tables and text that that describe the DomainParticipant (section
    2.1.2.2.1.

    Also for the specialized Entity classes, the operations are not
    mantioned on the class table but do appear in the text that describes
    the table. This applies to Topic (section 2.1.2.3.2), Publisher
    (section 2.1.2.4.1), DataWriter (section 2.1.2.4.2), Subscriber
    (section 2.1.2.5.2), and DataReader (section 2.1.2.5.3).

    **PROPOSAL**

    In order to avoid ambiguity, the get_qos/set_qos operation should
    appear explicitly in all the aforementioned sections.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-36 Entity_specialization_set_get_qos

  • Key: DDS-62
  • Legacy Issue Number: 6768
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification shows these operations as being abstract on the
    base-class (Entity) and says that it will be overridden by each
    specialization (Section 2.1.2.1.1.3). This is consistent with the PSM.

    However, the get_listener/set_ listener operations are not mentioned
    in the tables and text that that describe the DomainParticipant
    (section 2.1.2.2.1.

    Also for the specialized Entity classes, the operations are not
    mantioned on the class table but do appear in the text that describes
    the table. This applies to DomainParticipant (section 2.1.2.2.1),
    Topic (section 2.1.2.3.2), Publisher (section 2.1.2.4.1), DataWriter
    (section 2.1.2.4.2), Subscriber (section 2.1.2.5.2), and DataReader
    (section 2.1.2.5.3.

    **PROPOSAL**

    In order to avoid ambiguity, the get_listener/set_listener operation
    should appear explicitly in all the aforementioned sections.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Single waitset attached to condition

  • Key: DDS-60
  • Legacy Issue Number: 6766
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Ref-27 Single_waitset_attachement_to_condition

    Section 2.1.2.1. Why can only one "WaitSet" be associated with a
    "Condition". This contradicts figure 2-7 and figure 2-9.

    This seems too limiting. When this is combined with the fact that each
    entity has a single status condition we end up in a situation where
    one thread can wait on an entity changing states.

    **PROPOSAL**

    Correct section 2.1.2.1 and figure 2-5 to indicate that it is possible
    to attach the same condition to multiple waitsets

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-20 Semantics_of_factory_delete_methods

  • Key: DDS-55
  • Legacy Issue Number: 6761
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification does not state what happens if the application tries
    to use an entity after it has been deleted by means of the
    corresponding "delete" operation on the factory. This is specially
    relevant in languages such as Java (or C++ when using the "var" types)
    that automatically maintain reference counts. Is the deletion delayed
    until the last reference is release?

    **PROPOSAL**

    Modify section 2.1.1.1 and ad the return code
    ALREADY_DELETED. Similarly add the "const ReturnCode_t RETCODE_
    ALREADY_DELETED = 9" to the IDL in section 2.2.3

    State that it is an error for the application to use an entity after
    it has been deleted. Also state that, in general the result is
    unspecified and may depend on the implementation or the PSM. Also
    state that in the cases where the implementation can detect this, the
    operation that uses the deleted entity should return RETCODE_
    ALREADY_DELETED (e.g. calling DataWriter::write on a data writer that
    has been deleted).

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-15 Behavior_on_deletion_from_wrong_factory

  • Key: DDS-59
  • Legacy Issue Number: 6765
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification does not mention what to do when an entity is passed
    to a delete method in a factory object, for which that factory object
    is not owner? (For example a DataWriter is passed to the
    delete_datawriter method of Publisher A, while it was created in
    Publisher B.)

    This applies to Sections: 2.1.2.2.1.2, 2.1.2.2.1.4, 2.1.2.2.1.6,
    2.1.2.2.1.8, 2.1.2.2.1.10, 2.1.2.4.1.6, 2.1.2.5.2.6, and 2.1.2.5.3.7

    **PROPOSAL**

    State that if said "delete" operations are called passing the wrong
    factory, the operation shall fail and return PRECONDITION_NOT_MET.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-151 No_locally_duplicate_topics

  • Key: DDS-57
  • Legacy Issue Number: 6763
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification does not state what happens if the applcation
    attempts to create multiple times a Topic with the same name

    **PROPOSAL**

    In section 2.1.2.2.1.5 state that calling create_topic muiltiple times
    behaves as doing a lookup first with no timeout and if a Topic is
    found then it compares the data-type & the qos specified as parameters
    with those of the existing Topic.

    State that if the comparison fails, than the operation return
    PRECONDITION_FAILED.

    State that if the lookup and comparison succeed then the reference
    count to the Topic should be incremented such that the application
    must call delete_topic as many times as it called create_topic and
    directly lookup_topic for the local proxy to be deleted.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-62 Return_type_of_set_query_operations

  • Key: DDS-53
  • Legacy Issue Number: 6759
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.2.5.9. The set_query_arguments method is of type void, and
    can therefore not return an Error status.

    **PROPOSAL**

    Subsumed by proposal to Ref-50. Explicit operation to set the
    attribute will return ReturnCode_t

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    See issue 6758 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-87 Clarify_Topic_deletion_as_local_concept

  • Key: DDS-56
  • Legacy Issue Number: 6762
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.2.2.1.11 indicates that topics can be made globally
    available. So "creation" can have a global effect.

    It is not clear therefore whether deletion of a Topic also has a
    global effect.

    **PROPOSAL**

    Add to that paragraph in section 2.1.2.2.1.11. "In any case
    delete_topic deletes only the local proxy.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-22 Automatic_deletion_of_contained_entities

  • Key: DDS-58
  • Legacy Issue Number: 6764
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification describes that an entity cannot be deleted if it has
    contained entities. That is: Cannot delete Publisher if local
    datawriters. Cannot delete Pubscriber if local datareaders. Cannot
    delete DomainParticipant if any Topics, Publishers, Subscribers.

    However manually deleting all contained entities is cumbersome in the
    case in which the application is trying to do so as is the case when
    shutting down.

    **PROPOSAL**

    Add the operation "ReturnCode_t delete_contained_entities()" to
    DomainParticipant, Publisher, and Subscriber.

    This operation will return all contained entities and leave the system
    in a state that allows the application to delete the container. This
    affects sections 2.1.2.2.1, 2.1.2.4.1, 2.1.2.5.2, and 2.2.3 (IDL)

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming_of_attribute_getter_operations

  • Key: DDS-52
  • Legacy Issue Number: 6758
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Naming_of_attribute_getter_operations

    DataWriter class table, and DataReader class table operations
    get_liveliness_lost_status, get_offered_deadline_missed_status and
    get_offered_incompatible_qos_status.

    In the IDL file, these getter methods are specified as readonly
    attributes with the same names, but without the preceeding
    "get_". This leads to getter methods with different names in different
    languages (In C++ the"get_" part will disappear, in Java only the "_"
    will disappear).

    These IDL-to-language mappings would invalidate the PIM. To avoid
    this kinds of issues we should avoid using attributes in either the
    PIM or the PSM. The use of explicit operations will make the PIM more
    easily mappede to different PSMs.

    **PROPOSAL**

    Replace the readonly attributes in the PIM or PSM with explicit
    get_xxx operations. Replace any read-write attributes attributes in
    the PIM or PSM with explicit get_xxx and set_xxx operations.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Potential problems in PSM mappings

  • Key: DDS-51
  • Legacy Issue Number: 6757
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    ***Ref-05 IDL_case_sensitive

    In the PSM, the IDL uses as formal parameter names the same string as
    the name of the type only distinguished by the case. This appears to
    treat IDL as a case sensitive language which is not, and would result
    in problems in languages such as ADA that are not case sensitive.

    This problem appears in several paces where "topic" appears as the
    formal parameter name of an argument of type "Topic". For instance the
    operations TopicListener::on_inconsistent_topic,
    DomainParticipant::delete_topic, Subscriber::create_datareader
    Similarly "listener" appears as the formal parameter name of an
    argument of a type derived from Listener. For instance the operations
    DomainParticipant::create_publisher,
    DomainParticipant::create_subscriber, DomainParticipant::create_topic,
    DomainParticipantFactory::create_participant
    Publisher::create_datawriter, Subscriber::create_datareader

    **PROPOSAL** To avoid confusion use "a_topic" for the formal
    parameter name of any parameter of type "Topic", or any specialization
    of Topic.

    Similarly use "a_listener" for the formal parameter name of any
    parameter of type "Listener", or any specialization of Topic.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Obtaining the DomainParticipantFactory

  • Key: DDS-50
  • Legacy Issue Number: 6756
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    ***Ref-04 Initialization_of_DomainParticipantFactory

    The specification does not define how the application gets the
    DomainParticipantFactory if each implementation uses a different
    mechanism it would make applications non portable.

    **PROPOSAL**

    Modify section 2.1.2.2.2 adding the static operation "get_instance" to
    DomainParticipantFactory. This operation will return the factory which
    is a singleton. If the method is called multiple times the same
    factory is returned

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Delete dependencies and semantics

  • Key: DDS-54
  • Legacy Issue Number: 6760
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Delete dependencies and semantics

    ***Ref-19 Delete_dependencies

    Delete operations on Entities are only allowed if all other Entities
    which have dependencies with it have been deleted first (for example,
    a Topic may not be deleted before all other Entities depending on this
    Topic have been deleted first)

    The specification does not explain what happens if an application
    tries to delete an entity that has dependent or contained entities.

    This applies to Sections: 2.1.2.2.1.2, 2.1.2.2.1.4, 2.1.2.2.1.6,
    2.1.2.2.1.8, 2.1.2.2.1.10, and 2.1.2.2.2.2.

    Given that Topic object can be obtained by means of the
    DomainParticipant::create_topic operation as well as the
    DomainParticipant::lookup_topic operation there is an ambiguity
    regarding the deletion of Topic objects prior to deleting the
    DomainParticipant. Should the application call delete just on the ones
    it obtained by means of "create_topic" or also on the ones obtained by
    means of "lookup_topic"

    **PROPOSAL**

    State that if said "delete" operations are called while there are
    dependent or contained entities the operation will fail and return
    PRECONDITION_NOT_MET.

    Fix by adding get_datareader() operation to the ReadCondition. This
    operation should take no arguments and return a DataReader

    Also state that the application should also delete the Topic obtained
    by means of lookup_topic as this is needed to remote the local
    resources devoted to it.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectHome::get_topic_name (editorial

  • Key: DDS-46
  • Legacy Issue Number: 6752
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    This operation is not described in the text of section 3.1.6.3.5
    Proposal [THALES]
    add the description in the text (at the end of the operation list)
    "retrieve the name of the DCPS Topic that contains the value for one attribute (get_topic_name)"

  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectHome::get_all_topic_names (addition

  • Key: DDS-47
  • Legacy Issue Number: 6753
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    Getting all the names of all the topics that are used to store objects of a given class may be rather cumbersome
    Proposal [THALES]
    add an operation to get all in a single call
    IDL
    StringSeq get_all_topic_names()
    Concerns the PIM (figure, table and text) and the PSM

  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

stringSeq and longSeq (editorial)

  • Key: DDS-45
  • Legacy Issue Number: 6751
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    Rather name those types StringSeq and LongSeq as in DCPS
    Proposal [THALES]
    Actually 2 different naming rules conflict:
    list of xxx -> xxxSeq
    all user-created types starting with a capital letter
    Give the precedence to the second!

  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operations on collections of objects (addition

  • Key: DDS-48
  • Legacy Issue Number: 6754
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    Rather than returning a sequence of objects as the list of instances and let the application iterate in it, it seems better to let the infrastructure iterate by providing operations that would
    filter the objects
    apply a modifier on the objects
    Proposal [THALES]
    Introduce a new class FooExtent that would embed a sequence of Foo and provide those operations.
    Make the find_objects returning a FooExtent to allow to filter on a filtered result (like was allowed with the initial ObjectFilter::filter)
    Suppres the filter operation in an ObjectFilter (that is now redundant)
    Replace the list of instances in FooHome and FooSelection, by an instance of this class
    IDL
    local interface FooFilter : DLRL::ObjectFilter

    { boolean check_object (in Foo an_object); }

    local interface FooModifier: DLRL::ObjectModifier

    { void modify_objects (in Foo an_object); }

    local interface FooExtend: DLRL::OjectExtent

    { readonly attribute FooSeq objects; FooExtent find_objects (in FooFilter filter); void modify_objects (in FooFilter filter, in FooModifier modifier); }

    local interface FooHome

    { readonly attribute FooExtent extent; // instead of FooSeq }

    local interface FooSelection

    { readonly attribute FooExtent members;// instead of FooSeq }

    concerns the PIM (figure, list of interfaces, interface sections - table and text) and the PSM

  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Name of ObjectLink (consistency)

  • Key: DDS-49
  • Legacy Issue Number: 6755
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    This object is referred (in attributes or operations as refs (ex - refs, deref); therefore the name of the class ObjectLink is confusing
    Proposal [THALES]
    Rename this construct as OidRef
    Concerns the PIM (figure, list of entities, entities sections - tables and texts) and the PSM

  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CacheAccess::deref (clarification)

  • Key: DDS-44
  • Legacy Issue Number: 6750
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    What does deref when no corresponding object exist in the related CacheAccess or if the object has been deleted?
    Proposal [THALES]
    In that case, the deref operation should raise an exception (NotFound in the first case - cf. issue ref-1023, and Deleted in the second?)

  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    See issue 6748 for disposition – duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CacheAccess::delete_access (editorial

  • Key: DDS-43
  • Legacy Issue Number: 6749
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    The operation is badly named delete_cache in the PSM (instead of delete_access)
    The parameter is badly stated as CacheUsage (instead of CacheAccess) in the PIM (in the table for Cache operations)
    Proposal [THALES]
    Correct the PSM and the PIM table

  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Depth of cloning (addition)

  • Key: DDS-41
  • Legacy Issue Number: 6747
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    The ObjectRoot::clone operation takes as parameter an ObjectScope (only the object, the object + all its components, the object + all its components + all its related objects). In the latter case, this may result in cloning a lot of objects
    Proposal [THALES]
    Add an extra parameter to limit the depth of cloning for related objects, with a dedicated value for unlimited
    Precise that if some related objects are not cloned (depending on the ObjectScope and RelatedObjectsDepth) , traversing the related relation should raise the NotFound exception (cf. ref-1026)
    IDL
    typedef short RelatedObjectDepth;
    const RelatedObjectDepth UNLIMITED_RELATED_OBJECT_DEPTH -1;
    OidRef clone (in CacheAccess access,
    in ObjectScope scope,
    in RelatedObjectDepth depth)
    raises (ReadOnlyMode);
    concerns the PIM (table and text and the PSM)

  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CacheAccess operations (documentation)

  • Key: DDS-42
  • Legacy Issue Number: 6748
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    The operations of the CacheAccess are not sufficiently clearly described, that lead to some confusions
    Proposal [THALES]
    Enhance section 3.1.6.1.2.2 (Cache Management), in introducing better the underlying concepts; in particular, clarify the dynamics with respects to enable/disable updates
    Introduce that the specification is designed to allow lazy instantiation
    Describe more deeply the CacheAccess operations (section 3.1.6.3.2); in particular state how they will behave with respects to enable/disable updates
    Enhance the description of typical uses of CacheAccess (section 3.1.6.5)

  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Names of the ObjectRoot attributes

  • Key: DDS-40
  • Legacy Issue Number: 6746
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue [THALES]
    The attribute ObjectHome is named 'owner' and would be better named 'home'
    The attribute CacheAccess is named 'cache' and would be better named 'access'
    Proposal [THALES]
    change as indicated
    concerns the PIM (figure, table and text) and the PSM

  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Additional_qos_LIFESPAN Issue

  • Key: DDS-36
  • Legacy Issue Number: 6740
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2100 Additional_qos_LIFESPAN Issue [Boeing SOSCOE] ? The LIFESPAN Qos Policy that prevents “stale” data from being delivered to receiving applications. ? The LIFESPAN defines a time period for which the data should live. If a message cannot be delivered before the specified time period, the message is dropped. This value is expressed in time units, it should not be confused with a network-level Time-To-Live (TTL), that could be set on network connections which is expressed in number of hops. ? LIFESPAN is specified as a “span” that is a time interval measured from the time the data is written. ? LIFESPAN should be mutable. ? LIFESPAN needs to be specified only in the writer side. ? Note that this QoS assumes that the sender and receiving applications have their clocks sufficiently synchronized. ? The filtering could be done on the sending side, on the receiving side, or both. It would be an implementation decision that would only affect performance but would otherwise not be observable by the application. ? If data is dropped because the LIFESPAN value expires, Reliable and Transactional QoS would still require the writer to be notified of the failure to deliver. Proposal [Boeing SOSCOE] ? Introduce the LIFESPAN Qos.

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

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

: Attributes and operations directly set on valuetypes

  • Key: DDS-39
  • Legacy Issue Number: 6745
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    Currently the valuetypes ObjectRoot, RefRelation, ListRelation, IntMapRelation and StrMapRelation use a supported interface in order to gather their respective attributes and operations. This can be simplified in defining directly the attributes and operations on the valuetypes
    Proposal [THALES]
    define the corresponding attributes and operations directly in the valuetypes
    concern only the PSM

  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CacheFactory::find_cache (addition

  • Key: DDS-38
  • Legacy Issue Number: 6744
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    There in no means to retrieve a previously created Cache
    Proposal [THALES]
    Add on the CacheFactory::create_cache an extra parameter that is the name of the Cache
    Add the CacheFactory::find_cache method
    IDL
    Cache create_cache (in CacheUsage usage,
    in DCPS::DomainParticipant domain,
    in string name)
    raises (DCPSError, AlreadyExisting);
    Cache find_cache (in string name)
    raises (NotFound);
    concerns the PIM (figure, table and text and the PSM)

  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Additional_qos_DATA_PRIORITY Issue

  • Key: DDS-35
  • Legacy Issue Number: 6739
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2090 Additional_qos_DATA_PRIORITY Issue [Boeing SOSCOE] ? Need for additional DATA_PRIORITY Qos on the DataWriter. This Policy defines a priority that is associated with the data contained in a message and would serve two purposes: • 1) It would provide a prioritization mechanism for the transport, and • 2) It would determine how the receiver queues things in the data reader ? For the SOSCOE application this policy would have to support at least 5 values each with descending priority: (Flash_Override, Flash, Immediate, Priority, Routine) ? Ideally there would be a way to propagate and map this to whatever underlying transport is being used to send the messages. ? In its effect on the queuing on the receiving side it acts as a DESTINATION_ORDER QoS. In effect, the order would be BY_PRIORITY. ? Note that it would be possible to have DESTINATION_ORDER BY_PRIORITY and HISTORY KEEP_LAST. In this case, the reader may throw away the higher priority data if another message arrives. This is OK. If this is not the desired behavior, then the application should specify KEEP_ALL (which is expected to be the normal use in practice). Proposal [Boeing SOSCOE] ? Add a DATA_PRIORITY Qos.

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

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Make_USER_DATA_an_array_and_mutable Issue

  • Key: DDS-37
  • Legacy Issue Number: 6743
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2140 Make_USER_DATA_an_array_and_mutable Issue [Boeing SOSCOE] ? There are several potentially independent uses for USER_DATA. It would be useful to have it as a set of name-value pairs or other extensible construct. That way layers such as SOSCOE could add its own USER_DATA and not conflict with the uses that the application above SOSCOE may make of the data. ? SOSCOE has created a provider property class that allows applications to have attributes with typed values; it becomes a triplet (name, type, value). Currently the “type” only supports simple types, but the intent is to extend it to well-known structured types (ref Issue#2035). The extension of the USER_DATA can be used to implement these properties. Proposal [Boeing SOSCOE] ? Make USER_DATA a set of name-value pairs and make it mutable. ? Alternatively keep the USER_DATA as it is for the simple cases and add something more flexible for the more complex cases.

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

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Writer_notification_of_delivery_failure Issue

  • Key: DDS-33
  • Legacy Issue Number: 6736
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2070 Writer_notification_of_delivery_failure Issue [Boeing SOSCOE] ? This requirement applies to Point2Point and Group communications, not to Pub/Sub. ? In the case where the QoS is set to RELIABLE or TRANSACTIONAL there is a need for the application to be notified of delivery failures and also find out the delivery-status of individual messages. ? The application needs to get delivery confirmation with the granularity of a single message. ? Notification of delivery can be either synchronous (wait for delivery) or asynchronous (notification via listener). Proposal [Boeing SOSCOE] ? Add DataWriterListener::on_sent_data_lost and DataWriterListener::on_sent_data_received listener methods to notify sender asynchronously of reliable message send status ? Add UserListenerData for use in transactional and reliable processing. This data is specified on each write() and given back to the user through the DataWriterListener::on_sent_data_lost and DataWriterListener::on_sent_data_received methods to help the user determine what should be done with the data. ? Provide a way to get the ID of each message written (WriteMessageID). This can be used by the user to learn more about the message that was lost or received and is used by the system to track transactional and reliable messages that might have to be present. This id is passed to the on_sent_data_lost and on_sent_data_received listener methods and could become invalid at the end of those methods (the system must have some consistent way of determining when to clean up). Comment [RTI] ? In order for the application to find out the status of an individual message it needs to have some way to identify each message. Currently the DDS specification does not provide said mechanism. ? There are several ways to extend DDS to provide message identification functionality. • One way would be to change the return value of DataWriter::write() to return some kind of messageID or handle that can be used to refer to that message. Or alternatively return the messageId as an out parameter. However, this approach may complicate the application which now would need to perhaps track these IDs. • Another would be to add an operation to DataWriter to get the messageId of the last message written. This would have the advantage that it does not require a change of the API, just an extension. However, this would be potentially less efficient and also not safe if multiple application threads are using the same DataWriter to send information. • Another approach is that the MessageId would only be available by means of the callback. • With regards to the UserListenerData, it appears it needs to be either a parameter to the write call, or else something that could be set using a separate call. The first would clearly be more efficient but increases the complexity of the write API.

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

    duplicate, close

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Navigation_of_connectivity_information Issue

  • Key: DDS-34
  • Legacy Issue Number: 6738
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2085 Navigation_of_connectivity_information Issue [Boeing SOSCOE] ? There is no way to use the DDS API to find some of the information that is available internally to the service. ? For example there is no way to determine & enumerate the remote readers that are “associated” with a local writer, or the remote writers associated with a local reader. ? The DDS specification does provide a way to “name/identify” the remote entities. This is the DCPSKey that appears as part of the fields of the built-in-topics which are the ones used to access discovery information on remote entities. Proposal [Boeing SOSCOE] ? Add iterators to the DataReader and DataWriter entities that allow enumerating the remote entities (identified by DCPSKey) associated with it. ? Add helper operations that allow determining the QoS associated with remote entities (identified by DCPSKey)

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

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Extension_to_the_partition_qos

  • Key: DDS-31
  • Legacy Issue Number: 6731
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2030 Extension_to_the_partition_qos Issue [Boeing SOSCOE] ? The DDS specification provides the means for an application to configure the “connectivity” of DataReaders and DataWriters by setting the PARTITION QoS on the corresponding Publisher and Subscriber. ? Partitions therefore provide means for publishers and subscribers to restrict the associations that can be established between the readers and writers they contain. ? This facility is useful, but the fact that the matching is done by strict string matching of the partition-name strings can be limiting. ? It would be desirable to have something more extensible like “name-value” pairs and some more flexible expression language (e.g. a filter expression) to indicate the matching, beyond pure string matching. ? SOSCOE has created a provider property class that allows applications to have attributes with typed values; it becomes a triplet (name, type, value). Currently the “type” only supports simple types, but the intent is to extend it to well-known structured types (ref Issue#2035). ? A potential use case is to use name-value pairs to identify the source of the information or a distribution restriction. Things like AREA_NAME, SENSOR_GROUP, etc. each with its value. ? This is the analogous to the attribute-value pairs on the topic except they apply to the Publisher/Subscriber or EndpointConnectors. Proposal [Boeing] ? Addition of a set of name-value pairs to the Publisher and Subscriber (in fact to all Connectors) which can then be used to determine whether the endpoints contained in the connectors should communicate ? The attributes in the Connector can be used to locate providers of interest or somehow the “best” provider where “best” can be specific to each peer Connector. ? The query language described in Appendix A would not be sufficient for SOSCOE’s needs due to the need for function expressions and, at some future time, the ability to support well-known structured types (ref Issue#2035).

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

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Transactional_reliability Issue

  • Key: DDS-32
  • Legacy Issue Number: 6735
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2060 Transactional_reliability Issue [Boeing SOSCOE] ? For the case of Point2Point and Group communications there is a need to have “application-level” reliability where the sender can find out if a message was (1) delivered to the receiving application(s) and (2) whether it was successfully processed by the receiving application(s). ? SOSCOE uses the name “TRANSACTIONAL” to refer to this kind of application-level message-processed confirmation. ? This would only make sense for HISTORY QoS KEEP_ALL. TRANSACTIONAL and KEEP_LAST would be considered inconsistent QoS settings. Proposal [Boeing SOSCOE] ? Add the kind TRANSACTIONAL to Reliability QoS policy ? Add DataReader::set_transaction_status (or some operation to allow receiving application to accept or reject a transactional message) ? Add listener operations to the DataWriter to get notified of the transactional status. Potentially add also a method to the DataWriter to query the transactional status. ? Add a DataWriter::rewrite(WriteMessageID). This only applies to EndpointConnectors or GroupConnectors that have transactional QoS set. This handles the case where the message was transmitted to the receiving end and put on the reader queue successfully but the reading application does not set the transactional status indicating that the message was processed. The rewrite() is a convenience so that the writing application does not have to re-create the message but is being treated by the infrastructure as a message that needs to be sent again because the reader has presumably erased it from its queues.

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

    duplicate, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Attributes_on_a_topic_description

  • Key: DDS-30
  • Legacy Issue Number: 6730
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Attributes_on_a_topic_description Issue [Boeing SOSCOE] ? Some use-cases need more control on association of DataReader and DataWriters beyond the control offered by means of the Topic ? For example, SOSCOE may need to add a layer on top of the DDS API to offer additional customized services to the applications that sit on top. These services may include the propagation of identity-certificates, security, dynamic selection of the “best” DataWriter to use for a given Topic, etc. ? These mechanisms would like to benefit from the propagation of Topics and QoS that DDS offers and extend that mechanism with additional information that can then be used by the SOSCOE layer to provide these additional services. ? However the matching that DDS offers is performed only on the topic name. It would be useful to have a more extensible mechanism to allow matching on other application-defined attributes. ? These attributes are an expansion of the topic_name that appears in the TopicDescription. In addition to the string (topic_name) we could have a set of attribute-name/value pairs that could then be used to match the writers with readers. In a sense the topic_name would be a singular, mandatory attribute used for matching but they could be others. ? These attributes are not mutable. ? SOSCOE has created a provider property class that allows applications to have attributes with typed values; it becomes a triplet (name, type, value). Currently the “type” only supports simple types, but the intent is to extend it to well-known structured types. ? For example, the Topic “weather data” would describe a general topic but there may be an attribute that describes the region (e.g. “North America”) and the subscriber can specify they want weather-data but only over “North America” Proposal [Boeing SOSCOE] ? One approach would be to add a set of “name-value” attributes to the TopicDescription. Matching would be done not only on the topic-name but also on the remaining attributes. In a sense, the topic name is just one of the attributes that must be matched between the Topic that is published and that which is subscribed.

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

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Additional_communication_paradigms

  • Key: DDS-29
  • Legacy Issue Number: 6729
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2010 Additional_communication_paradigms Issue [Boeing SOSCOE] ? In addition to the Data-Distribution model, our applications also need two basic communication models; Point2Point and GroupCommunications. ? The API’s and PIM defined in DDS would fit well with those communication models as well. That is, the concept of typed DataReaders and DataWriters that are configured by means of QoS and interact with the user-level application by means of listeners and conditions are all applicable to Point2Point and GroupCommunications. ? It would therefore be useful to introduce extensions such that the application can use these additional communication models in a way that fits naturally with the data-distribution PIM. ? In Boeing SOSCOE’s applications Point2Point communications: • Represent 1-to-1 bi-directional communication channels similar to UNIX “pipes” that can be configured by means of QoS • Are “connection-oriented” in the sense that each endpoint must explicitly establish the “connection” and is made aware if the “connection” is broken • Allow the application to read-write typed data to the other end-point. Each “writer” in one side of the connection communicates with the corresponding “reader” at the other end. In general each writer must be matched by a reader at the opposite end. Otherwise it is a configuration error. • Allow prioritization among the data written by different writers by means of QoS • Allow both synchronous and asynchronous writes. • Support the concept of application-level acknowledgements or “transactional” messaging by which the writing application can receive notification that the reading application has received the message and has positively acted on it. • Support the classic “client-connect versus server-listen/accept” pattern such that the “server” side can establish multiple dedicated point-to-point connections to each “client” that requests a connection. • Filters are not generally expected to be required for Point2Point communications. However, in order to keep the same API they should be allowed. The middleware should automatically give positive acknowledgement of reliable or transactional data that has been filtered out. • It is an error for a data-writer to write a Topic that does not have a corresponding data-reader. The writer() call should return a special error code indication there is no matching DataReader. In Boeing SOSCOE’s applications GroupCommunications : • Provide the capability for a group of peer applications to organize themselves into a “group”, such that each member of the group is aware of the presence of all other members and can send messages directed to either one specific peer, all the peers in the group, or a subset of the members of the group. • Provide some means to control group membership. • Each member of the group is identified by some “ID” such that other members can refer to it and direct messages to it. • Provide a serialized view of membership and delivery of messages such that: • The writer knows the membership when it sends each message and anybody that does not belong to that membership will not get the message. • All members of the group have the same view of the membership for each message delivered to them. • Do not need to provide total order or even agreed order. • Act as a “live” group in that messages are only delivered to the members that are present when the message is sent. In other words, it does not store messages on behalf of future members of the group • It is OK to write a DataWriter that does not have a corresponding DataReader on some of the other Group members. The data is considered acknowledged for RELIABLE but not for the purpose of TRANSACTIONAL (ref issue# 2060). Proposal [Boeing SOSCOE] ? Consider introducing a more primitive concept for a group of endpoints, from which the following classes derive: Publisher, Subscriber, EndpointConnector, and GroupConnector. ? This base class could be called “Connector” but does not really mean a “connection” in the “TCP” sense, rather the “connectivity” into the middleware services. ? All these “Connectors” act as factories for DataReader and DataWriter entities (which represent the Endpoints). ? The type of the DataReader and DataWriter created from each kind of “Connector” is the same (even though they will act differently). This is because the DataReader and DataWriter are typed facades to write a specific data-type and it is not desirable to have to create (by means of implied IDL) different types for each kind of connector. ? The EndpointConnectors and GroupConnectors are informed of the connections/disconnections by means of Listeners with an “onConnect” and “onDisconnect” operations. ? For Point2Point communication the factory of DataReader and DataWriter entities would be the EndpointConnector • To match the two EndpointConnector objects that should be “hooked up” the application could use either a Topic, or a more general matching of “Attibute-value” pairs, or a combination of the above. • To aid in the establishment of many point2point connectors using the client-connect, server-listen/accept pattern the EndpointConnector could use an auxiliary “ServerConnector” and corresponding listeners that would inform it of the fact that clients are attempting a connection. ? For Group communications the factory of DataReader and DataWriter entities would be the GroupConnector • The same generic mechanism used by the EndpointConnector should be used to identify the group the GroupConnector entities are joining, that is either a Topic, or a more general matching of “Attibute-value” pairs, or a combination of the above. Comments[RTI] ? To avoid confusion it might be a good idea to propose a name other than “connector” for the base class and also avoid the use of the terms “client” and “server” which are often associated with the pattern of communications used by CORBA and RMI. ? Point2Point communications would never use KEEP_LAST QoS. They will use KEEP_ALL. They will also always have DURABILITY TRANSIENT. In a sense messages are sent to the other end “immediately” and held only as long as is necessary to ensure the QoS (e.g. RELIABLE or TRANSACTIONAL) afterwards they are removed from the middleware.

  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Closed; No Change — DDS 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1017: Section 3.1.4.4.2 topic (editorial

  • Key: DDS-26
  • Legacy Issue Number: 6721
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    1st bullet: section 3.1.4.4.2 (Mono Attribute) Class::topic should be Class::main_topic
    Proposal [THALES]
    correct the wording

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1019: Name of the ObjectRoot::clone method (editorial)

  • Key: DDS-28
  • Legacy Issue Number: 6723
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    in section 3.6.1.3.11 the clone method is named clone_object in the text explanation.
    Proposal [THALES]
    correct the text (everywhere else, the method is named clone)

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1016: Page 3-65 t2 (editorial)

  • Key: DDS-25
  • Legacy Issue Number: 6720
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    page 3-65: 4th line from below: t3->z(3000.0); t3 should be t2
    Proposal [THALES]
    correct the example

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1015: Page 3-62 manual edition (editorial)

  • Key: DDS-24
  • Legacy Issue Number: 6719
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    page 3-62: Just after the XML listing: manual edition should be manual editing
    Proposal [THALES]
    correct the sentence

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1018: Name of the methods for ObjectListener (editorial)

  • Key: DDS-27
  • Legacy Issue Number: 6722
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    In section 3.1.6.3.6 (ObjectListener) the method names used in the bulleted descriptions do not correspond to the names used in the Table
    page 3-38: section 3.1.6.4.2 (Object Creation) first bullet: two times on_object_created is mentioned according to figure 3-4 this should be on_new_object.
    Proposal [THALES]
    correct the table (the bullets are in accordance with the IDL)
    correct the figure (on_object_created is the name of the operation in other places, including IDL)

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1013: Section 3.1.6.3.9 Table for ObjectQuery (editorial)

  • Key: DDS-22
  • Legacy Issue Number: 6717
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    attribute "parameter" is stated as of type "string[}" instead "string []"
    Proposal [THALES]
    correct the table

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1014: Page 3-10, figure 3-2 min_topic (editorial)

  • Key: DDS-23
  • Legacy Issue Number: 6718
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    page 3-10: In figure 3-2 the class attribute min_topic should be main_topic
    Proposal [THALES]
    correct the figure

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    correct the figure

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1010: Section 3.2.3.3 XML Model Tags of the example

  • Key: DDS-19
  • Legacy Issue Number: 6714
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    In the final editing process,
    the XML for the example has been truncated (cut by 2)
    the chosen font makes it difficult to read (why not use Courier New which is a fixed-sized font as for the code example)
    there should be a void line between the first sentence that introduces the XML description and the description itself
    Proposal [THALES]
    restore the contents as it was in version V67
    introduce a void line to keep it separated from the introduction

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1012: Section 3.2.3.3 Simplified XML of the example)

  • Key: DDS-21
  • Legacy Issue Number: 6716
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    In the final editing process,
    the minimum XML model tags for the example have been truncated (cut by 2)
    the removal of the title makes less clear the purpose of the description
    Proposal [THALES]
    restore the contents as it was in version V67
    change the last sentence of the introduction " In this case, the XML file would be as follows" with
    "In case no deviation is wanted from the default mapping, the XML description can be restricted to the following minimum:"

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1009: Section 3.2.3.2 IDL Model description of the example

  • Key: DDS-18
  • Legacy Issue Number: 6713
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    in the final editing process, the IDL for the example has been truncated (cut by 2)
    Proposal [THALES]
    restore it as it was in version V67

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1006: Page 3.11 (editorial)

  • Key: DDS-15
  • Legacy Issue Number: 6710
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    On that page, "Class", "Attribute" and "Relation" (line 2) and "Class" (first line before section 3.1.4.4.3) should be in bold+italics as the other words that are identifiers
    Proposal [THALES]
    Correct the words

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1011: Section 3.2.3.3 Introduction to figure 3.9 (editorial)

  • Key: DDS-20
  • Legacy Issue Number: 6715
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    The style applied to the introduction to figure 3.9 is not correct
    The figure itself is badly placed on the page
    Proposal [THALES]
    Correct the footprint

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    Correct the footprint

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1005: figure 3.2 (editorial)

  • Key: DDS-14
  • Legacy Issue Number: 6709
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    In the class "Relation", the attribute "rel_needs_class" should be named "full_oid_required" (according to the text description)
    In the class "Class" In the class "Relation", the attribute "id_needs_class" should be named "full_oid_required" (according to the text description)
    Proposal [THALES]
    Correct the figure

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    Correct the figure

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1008: Bad annex reference (editorial)

  • Key: DDS-17
  • Legacy Issue Number: 6712
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    in the whole DLRL section, Annex C is badly named Annex A
    Proposal [THALES]
    Change all the "cf. annex A", with "cf. annex C"

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1007: Section 3.1.6.3.4 CacheListener (editorial)

  • Key: DDS-16
  • Legacy Issue Number: 6711
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    In the textual description, the method "on_begin_updates" is named "start_updates"
    In the textual description, the method "on_end_updates" is named "end_updates"
    Proposal [THALES]
    Correct the textual description to align on the table.

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1004: Section 3.1.3.3 Metamodel (clarification)

  • Key: DDS-13
  • Legacy Issue Number: 6708
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Several readers wondered if the described metamodel should be implemented, while it is only given for description purpose
    Proposal [THALES]
    Add the following clarification sentence (at the end of the first paragraph of the section page 3.4):
    " This metamodel is given for explanation purpose. This specification does not require that it is implemented as such."

  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT