DDS 1.0 NO IDEA Avatar
  1. OMG Issue

DDS — DDS ISSUE# 31] Topic QoS refactor

  • Key: DDS-111
  • Legacy Issue Number: 6817
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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