DDS11 — Attributes_on_the_data

Attributes_on_the_data Issue [Boeing SOSCOE] ? The DDS API forces the data to be written to be encapsulated into a single IDL structure. Moreover IDL-generated structures do not support pointers to other structures. ? These limitations are constraining the kinds of things that a layer such as SOSCOE can do. For example, it would be desirable to allow the DDS DataWriter to filter or perform other actions on information that is not “part of the data”. Not “being part of the data” means the attributes: • Are propagated along with the message (1-to-1 relationship) to the reader. • May be used for filtering, or intercepted by layers above DDS (e.g. SOSCOE). • Do not get passed to the read or take calls ? The problem is that since the DataWriter takes a single “compacted” data-structure, any additional information, whether introduced by the user-app or the SOSCOE layer must be somehow copied into the data and thus force the introduction of new data-types. ? In other words it would be desirable for DDS so provide some hook that would allow a user or a layer such as SOSCOE to add additional information to the “user-level” data that is then used by DDS to filter on. The filtering would then occur on the additional information provided by the SOSCOE layer and not by the application that is writing the data. There are three main ways to use this • The additional SOSCOE information, would be supplied in conjunction with every write operation. So the filtering is evaluated on every write. This may be too inefficient in some cases and therefore there should also be a way to turn off the filtering also (e.g. by providing an empty set of attributes). • The additional SOSCOE information is provided by some other means than a parameter to the write (e.g. a set_attributes(InstanceHandle_t, Attributes)) call on the DataWriter) so that the filtering does not examine every data-sample for filtering; rather it is performed on information that changes at much slower rate. For example, there is the concept of a “geographical region” in which the information lives; the filtering applies to getting information that is within our region of interest, and re-evaluation of the filter only occurs each time the region changes which is much rarer than the actual data changing. • The attributes could be attached to the instance by means of a separate API. These additional attributes would then be passed to the serialization as well as the filter operations. The deserialization would also need to handle them. This approach would meet SOSCOE’s requirements and has the advantage of not forcing filters to be re-evaluated each write; they would only be evaluated if the attributes change. Proposal [Boeing SOSCOE] ? Add a set of attributes (name-value pairs) (ref Issue#2035) that are provided separately from the data and can then be used to do the filtering. ? This allows reusing the same data with different attributes and thus filter it differently. ? Name-value pair representation would also potentially allow sending a partial list of attributes ? Filtering can be done on this name-attribute pairs. Similar to ContentFilteredTopic but the filtering is done on the attributes, not the data. Note that the ContentFilteredTopic may not know enough about the data. The data may be marshaled and encrypted. The brokering of the data may be done by nodes that do not know how to unmarshal/decrypt the data.