Rework the Data Type Hash to accommodate polymorphic types

[pavel-kirienko]

See #60

Under the definition provided in "Alternative Transport Protocols", data type hash makes the network too rigid and incompatible with polymorphic types. I have removed this experimental implementation from PyUAVCAN following the discussions on the forum and #64.

[pavel-kirienko]

The viability of moving the data type hash from the frame header into the payload segment (that is, changing the layout so that the data type hash is not carried with each frame but only once per transfer) should be assessed. Pros: less overhead. Cons: reduced context per frame complicates diagnostics (esp. postmortem) and makes acceptance filtering by data type impossible.

[pavel-kirienko]

Interesting industry examples (find an overview in my recent post on Data type extensibility and composition:

1. DDS defines rigorous type compatibility and extensibility model. While extensive, their model has the disadvantage of being complex (undesirable for UAVCAN, where U stands for uncomplicated) and limiting (aliasing is made impossible). Also, the means of assessing compatibility via a dedicated QoS policy as defined by DDS are hard to apply to UAVCAN due to its more stateless nature. Still, DDS is a highly successful and masterfully architected technology that should be looked up to.

2. Cap'n'Proto takes a simpler approach that is closer in spirit to UAVCAN: it delegates the compatibility issues to the developer by requiring that each file has a randomly-assigned 63-bit unique ID. Then, definitions that are considered compatible (coercible, assignable) by the developer (as opposed to DDS where the decision is ultimately made by the machine) would simply share the same unique-ID. This obviously permits free renaming and modification assuming (boldly) that the developer is careful enough. This approach is not directly transferable to UAVCAN though because it is incompatible with structural subtyping, where different types may still be assignable despite being independent of each other.

For now the Data Type Hash should be just set to zero when transmitting and ignored when receiving. It may be changed in a future revision of the protocol if an adequate solution for the automatic runtime type assignability check is found.

[pavel-kirienko]

Related work: https://forum.uavcan.org/t/type-safety-enhancement-proposal/1416

Methods of mapping such string signature to a numerical data type hash should be explored. One (raw) idea is to represent each entry in the signature as a product (or power) of two primes: one is defined by the index of the entry, the other is its type. Proper arrangement provided, two types can be assumed to be compatible if the data type hash of one is a factor of the other.