As I sat down to write an abstract for the upcoming presentation, I had to take a broad look at what we are doing here. The broad look revealed (among other things) that we might be heading towards an undesirable duplication of effort on the front of the transport data logging feature. It could be that in the future (in fact, I would say in the very near future) we may want to define a yet another (very trivial) experimental transport protocol for point-to-point raw serial links like UART/RS-232/RS-485/USB-CDC-ACM (which would be close to what they do with DDS-RTPS out there). A plain serial link is similar in terms of data layout to the log files I’ve been talking about in this thread so we could avoid redundant efforts by defining a serial transport first and then using it for transport log storage on disk. The serial transport could be supremely simple; say, this trivial header format comes to mind immediately:
uint8 version ~ 0
uint8 priority # Like IEEE 802.15.4: bits 7..5 - priority
uint16 source node ID # 0xFFFF = anonymous
uint16 destination node ID # 0xFFFF = broadcast
uint16 data specifier # Like IEEE 802.15.4: subject ID or service ID + request indicator
uint64 transfer ID
uint64 compact data type ID
uint32 frame index EOT # Like IEEE 802.15.4: MSB set in the last frame, cleared otherwise
uint8[] payload
We could then define a new union data type in the standard data type set that would encapsulate transport-specific frame data. The resulting structure would be very simple thanks to its recursive dependency on itself: serial transport frames stored on disk would contain transfers containing serialized representation of messages containing the logged transport-specific frames. I am going to expand on this idea someday later.