QoSProviderDelegate implementation missing

[ForethoughtOfGosport]

We are trying to use Cyclone DDS, currently using a much older version (OpenSplice Vortex DDS) and in that we use a QoS provider based on XML files.

Reading e.g. issue 277, it is clear that the XML QoSproviderDelegate item is on a todo list.

Our code fails to link because while there is a header file defining this in src/ddscxx/include/org/eclipse/cyclonedds/core/QosProviderDelegate.hpp, there is no implementation.

We use mostly static QoS profiles from XML files, with a small amount of dynamic adjustments.

What is the most likely future implementation of this QOS provider code ?

I can see from the older C source in Opensplice Vortex DDS that this was a complex local implementation of an XML database with search from first principles.

Am I right in assuming that this code would most likely be replaced with something based on an external library?

Is there any progress on this todo , or some way we could contribute ?

[eboasson]

Hi @ForethoughtOfGosport, it is just a tedious bit of work that needs to be done in C to read the XML and construct dds_qos_t * based on it, and then a small bit of code in the C++ binding to make the functionality available there as well.

Cyclone has its own almost-XML parser (should be good enough for this) in https://github.com/eclipse-cyclonedds/cyclonedds/blob/master/src/ddsrt/src/xmlparser.c, which simply does callbacks for everything it encounters. You need to maintain enough state to know what children are valid and where to store the data.

The QoS representation in Cyclone differs from what the OMG specifies in its API definitions (and what OpenSplice does), because all settings are optional in the dds_qos_t object, and moreover you can safely pass a QoS object containing settings that do not apply to the entity being created. So if you encounter, e.g., a data reader QoS in the XML, you can just call dds_create_qos and then for each setting you call the corresponding dds_qset_... function. Put these in a table and you're pretty much done. You can even leave validation to the entity creation functions.

IINM the spec allows inheritance, but that, too, is native to Cyclone's QoS representation, all you need to do is walk the inheritance hierarchy, calling dds_merge_qos along the way.

So the only real work is in making sense of the XML elements as you encounter them, plus the tedious bit of writing code to convert text-based values to QoS settings. This is very much like the configuration processing, and if I had to do it, I'd probably take that and strip it for everything I don't need. (But I have an unfair advantage because I wrote that bit once upon a time ...)

As for the API, if you'd do all the inheritance at load time, then you'd end up with a table of QoS's that you can pass straight into the entity creation functions, for example by defining a function const dds_qos_t *dds_lookup_qos(...). Then you could write: dds_create_reader(..., dds_lookup_qos(...), ...) and it will magically work if a QoS library has been loaded and the requested QoS is defined.

That does leave an issue with error handling: you can't return a null pointer if the QoS lookup fails, because that means "default QoS". For this, I'd be tempted to add an INVALID flag to the QoS object and then make all functions that take a QoS fail immediately if this flag is set. Then a lookup failure in dds_lookup_qos could simply return a pre-defined empty QoS object marked as invalid, and all would be well without any need to check or to manually allocate/free QoS objects in the application code.

As to where I'd put it: enough people have asked and it simple enough that I think it could just go into the core library. I would make it compile-time option, though, simply because I still care about embedded platforms.

If doing (some of) the above is something you'd be willing to look into, then that could definitely be a way to speed up the process.

[ForethoughtOfGosport]

Thanks for the heads-up. I shall take a look

[mav5499]

Hello, I saw that QosProvider was just implemented in the C library. Is it in a good state to implement this in the C++ bindings?