DDS-XTypes 1.0 FTF Avatar
  1. OMG Issue

DDSXTY_ — New DDS-XTypes issue: inability to consume data using new base class

  • Key: DDSXTY_-18
  • Legacy Issue Number: 16561
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    have a new issue to file against the DDS-XTypes spec that was pointed out to me by Reinier Torenbeek.

    Declared compatibility of types (i.e. type signature) includes base types but not derived types. Unfortunately, that means that a consumer using a base class unknown to an existing producer will not be able to consume data from that producer, because neither party will declare the relationship between the types.

    For example: I publish Dog, which extends Animal. In version 2, a new intermediate class Mammal is introduced. However, a new consumer of Mammal won't match with a legacy producer of Dog, because both the Dog and Mammal endpoints declare that their types extend Animal, and neither one asserts that Dog should now extend Mammal.

    Proposed Resolution:

    Remove the type signature concept and go back to registering simple names. In its place, introduce a new QoS policy that lists assertions about which types extend which others. Consider making these assertions transitive. As today, the operative set of assertions when matching producers and consumers should be the union between the producer's and the consumer's sets.

  • Reported: DDS-XTypes 1.0b2 — Tue, 20 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Remove the type signature concept and go back to registering simple names

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