eclipse-ecal
Protobuf descriptions (for inspecting the payload in eCAL monitor)
I was wondering why my protobuf messages are not being rendered in eCAL monitor. I even thought that it's an issue in eCAL, and submitted a ticket. However, I got a very helpful answer explaining that eCAL nodes should normally be able to provide the description of messages, which allows eCAL monitor to display them nicely. However, ecal-rs doesn't implement it at the moment.
The issue is around this line: https://github.com/kopernikusauto/ecal-rs/blob/5fdc9e101f7df119111f2fdef809f77a478218a0/src/lib.rs#L163
I found this protobuf crate. Seems to me that they can extract the descriptor out of the protobuf type.
For language bindings (both Python and C#) the wrapping of the functionality is done on binary Publisher / Subscriber level. Protobuf Publishers / Subscribers are one layer above that, and contain functionality (serializing, deserializing, registering type and descriptor information).
These parts are done in the respective language bindings. So it's implemented for C++, but also for the language Bindings. Most of the time there is some helper functionality, e.g. to create a descriptor string from a given protobuf type, and then the code for publishers / subscribers themselves:
Python protobuf publisher: https://github.com/continental/ecal/blob/bc13f25394eae4e06452824a63f8c042c7bc206d/lang/python/core/ecal/core/publisher.py#L83
Python protobuf helper functionality: https://github.com/continental/ecal/blob/bc13f25394eae4e06452824a63f8c042c7bc206d/lang/python/core/ecal/proto/helper.py#L44
Python example usage: https://github.com/continental/ecal/blob/bc13f25394eae4e06452824a63f8c042c7bc206d/samples/python/person_snd/person_snd.py#L40
Basically, the python constructors take a type and descriptor string, and the helper functionality calculates this info from the protobuf type. As C++ is statically typed, the functionality is implemented in a typesafe way (class templated on protobuf type), in Python the type is passed in constructor.
So basically you will have to implement the same for Rust. To build on basic publishers / subscribers to add the required functionality. We really have to improve documentation on these topics, but we probably also want to restructure code a bit internally, so it reflects the efforts that has to be done
