Test unions, enums, valuetypes, and other IDL features

[grahonan]

In order to detect type interoperability issues between DDS vendors, we should test new types that use unions, enums, valuetypes, and other IDL features.

We had a recent interoperability issue between Connext and CoreDX, so we should at least begin testing unions and enums, e.g.

enum MyEnum {
      MY_REGION,
      MY_VOLUME
  };
 
  struct MyRegion_T {
      long x;
  };
 
  struct MyVolume_T {
      long y;
  };
 
  union MyUnion switch(MyEnum) {
      case MY_REGION:
          MyRegion_T theRegion;
      case MY_VOLUME:
          MyVolume_T theVolume;
 
  };
  struct myType {
      MyUnion test;
  };

[ClarkTucker]

Yes, I agree.

I was wondering about loading Types and Data from XML. It might be worthwhile to use that mechanism instead of putting all the types and data into code -- it gets rather verbose as we add types (especially when we need to check a variety of data with each type).

If the pub and sub are both configured to load a 'type' and a 'data sample' from XML, then the pub can create and send a sample, and the sub can read and verify the sample.

Thoughts?

[grahonan]

Hi Clark, I think this is a great approach. My only concern is that maybe not all DDS vendors support XML types, or maybe they don't all support XML types in the same format? I only use Connext, so I'm not sure what would be the best "universal" approach that all vendors could easily participant in.

[ClarkTucker]

Yes, that is a valid concern. The XML encoding of types and data is an optional component in the spec, so not safe to assume that all vendors implement it. I don't know what the state of support is from other vendors... only that Twin Oaks does support it (and I assume RTI does as well, but not positive).

It sure would make it much easier to build new test cases (no recompile required) which is a huge benefit.

[grahonan]

I work for RTI and I can confirm we support it.