Unify CDR serialisation

[danieleades]

serialisation in this crate uses a mixture of Speedy and Serde. Ideally, you'd want to converge on a single solution.

Another goal is to decouple the types from their "on-the-wire" representations. I want to help resolve this (if I can!).

Since this is a big task, requiring a lot of iteration, I would suggest creating a new branch for experimentation? Have you got any thoughts about how to approach this @jhelovuo?

[jhelovuo]

The description above is not completely accurate.

Serde is used for serialising application (payload) data, whose structure we do not know beforehand. Serde's derive macro is very handy here. DDS default serialisation format for application data is CDR, so we provide an implementation for that. We have SerializerAdapter and DeserializerAdapter traits to decouple Serde from RustDDS. I think the application data could be (de)serialised completely without Serde, if the adapters are used to attach some other serialiser library in Serde's place. We are still dependent in Serde in serialising the built-in Discovery data.

Speedy is used to process the RTPS protocol headers and other control data. These have fixed content and format. Some parts of the protocol cannot be independently decoded by Speedy, so some of the implementations are hand-written. Mostly because submessage contents cannot be decoded without looking at some flags from submessage header, which is decoded separately.

Now that I think of it, Speedy could be used better by restructuring the submessages: Instead of keeping submessage header and body separate (neighbouring fields in a struct), the data should be restructured so that we always decode the submessage as one unit, both header and body. Then we have the header flags locally available to decode the body. Submessage header is just one machine word in size.

While I understand the architectural goal of separating logical representation from the wire format, I see little gain in doing that all over the place. Most of the data items are too simple to gain significant benefit from that.

[danieleades]

fair enough. thanks for the detailed response. Maybe I should just close this until there are some more concrete requirements for the serialisation. Where do you see this going? or are you happy with the current approach?

[jhelovuo]

I am quite happy with the current status. If you spot similar redundancy or C++ leftovers as there were with ReliabilityKind, then those could be cleaned away, but I see nothing major here.