DDS and application configuration information

2 posts / 0 new
Last post
Last seen: 10 years 2 months ago
Joined: 07/30/2013
Posts: 1
DDS and application configuration information

I'm on a project that uses RTI's technology to implement DDS pub/sub in the project's applications.  Our main set of data types for use in DDS fall into two major classifications:  operational data and configuration data.  The operational data is dependant on the configuration data.  For example, I might have some IDL that describes a vehicle and that vehicle is dependant on some number of wheels.  Because DDS does not support pointers or polymorphism (like CORBA), in order to use DDS we have to know, ahead of time, how many wheels are needed for any particular vehicle.  This means using arrays with FIXED array sizes.  We then hand this set of IDL to different clients who then drop in their own configuration IDL that has those array values specified.  So all this configuration information has to be known at IDL compile time.  My clients would like to be able to drive that configuration at RUN-TIME.

Q)  Has anyone else faced this situation, and have they successfully found a way to support run-time configuration information?

Q)  Do I need to switch to some other form of containment other than arrays (like sequences) to accomplish my goal?




Bart Jenkins


rip's picture
Last seen: 4 min 31 sec ago
Joined: 04/06/2012
Posts: 324


Sequences are by implementation 0..n.  If you assume for example that your vehicles may have no more than 8 wheels, you can define a type that has

sequence<WheelType, 8> wheels;

Wire data only includes the number of wheels actually used.  So a unicycle would have wheels.size() = 1 and the serialized data would include only that one wheel (and zero space for the other 7 slots), a gamma goat would have size() = 6 and a hovercraft would be size() = 0, and this all happens in application code at run-time. 

Is that what you're looking for?

The cost/benefit analysis for array vs sequence I'll leave to others.