DDS15 — How to handle some GROUP ordered Subcriber scenarios

When using a GROUP ordered Subscriber, how do you access the samples in the order in which they are produced? The DDS1.4 specification says the following thing about this:.

"If the PRESENTATION QosPolicy of the Subscriber to which the DataReader belongs has the access_scope set to ‘GROUP.’ This operation should only be invoked inside a begin_access/end_access block. Otherwise it will return the error PRECONDITION_NOT_MET. Depending on the setting of the PRESENTATION QoS policy (see 2.2.3.6), the returned collection of DataReader objects may be a ‘set’ containing each DataReader at most once in no specified order, or a ‘list’ containing each DataReader one or more times in a specific order.

1. If PRESENTATION access_scope is INSTANCE or TOPIC the returned collection is a ‘set.’
2. If PRESENTATION access_scope is GROUP and ordered_access is set to TRUE, then the returned collection is a ‘list.’
   This difference is due to the fact that, in the second situation it is required to access samples belonging to different DataReader objects in a particular order. In this case, the application should process each DataReader in the same order it appears in the ‘list’ and read or take exactly one sample from each DataReader. The patterns that an application should use to access data is fully described in 2.2.2.5.1, Access to the data."

The big question here is: what happens when the user does not follow this scenario exactly? Here is a couple of potential deviations from the described scenario:

1. Reading more than one sample from every listed reader (i.e. use read/take with max_samples > 1)
   • We could state that no matter what the size of max_samples is, you get one sample at max.
2. Reading/Taking samples with different sample/view/instance state masks than passed to the get_datareaders() call.
3. Reading/Taking samples from a different reader than next one in the reader list.
4. you invoke get_datareaders() before having fully iterated through the previous reader list.

We should specify what happens if an application (intentionally or non-intentionally) does not follow the scenario laid out in the spec, or we should come up with an alternative reading mechanism that does not allow you stray off the correct path in these ways for example by introducing new function calls.