DDS — Extension_to_the_partition_qos

Issue# 2030 Extension_to_the_partition_qos Issue [Boeing SOSCOE] ? The DDS specification provides the means for an application to configure the “connectivity” of DataReaders and DataWriters by setting the PARTITION QoS on the corresponding Publisher and Subscriber. ? Partitions therefore provide means for publishers and subscribers to restrict the associations that can be established between the readers and writers they contain. ? This facility is useful, but the fact that the matching is done by strict string matching of the partition-name strings can be limiting. ? It would be desirable to have something more extensible like “name-value” pairs and some more flexible expression language (e.g. a filter expression) to indicate the matching, beyond pure string matching. ? SOSCOE has created a provider property class that allows applications to have attributes with typed values; it becomes a triplet (name, type, value). Currently the “type” only supports simple types, but the intent is to extend it to well-known structured types (ref Issue#2035). ? A potential use case is to use name-value pairs to identify the source of the information or a distribution restriction. Things like AREA_NAME, SENSOR_GROUP, etc. each with its value. ? This is the analogous to the attribute-value pairs on the topic except they apply to the Publisher/Subscriber or EndpointConnectors. Proposal [Boeing] ? Addition of a set of name-value pairs to the Publisher and Subscriber (in fact to all Connectors) which can then be used to determine whether the endpoints contained in the connectors should communicate ? The attributes in the Connector can be used to locate providers of interest or somehow the “best” provider where “best” can be specific to each peer Connector. ? The query language described in Appendix A would not be sufficient for SOSCOE’s needs due to the need for function expressions and, at some future time, the ability to support well-known structured types (ref Issue#2035).

see below