Serialization of federated messages

[erlingrj]

After our last meeting I am thinking about whether we should by default use protobufs, but with an opt-out for people that want to do their own serialization.

This would effectively mean that we must run nanopb protobuf compiler as part of code-generation or compilation. This means that the users must have installed nanopb Python dependencies to run the nanopb Python script for generating .c and .h files for the .proto files.

Another question is how the user should supply the .proto files for the federated ports. Wither they provide actual files to the build and just reference the message types in the port. E.g.

output out: MyProtoMsg

Would require there to be such a protobuf message defined in any of the .proto files provided to the build.

Or, as Edward noted, we could support native C types and could code-generate the protobuf message descriptions.

[edwardalee]

After yesterday's discussion, I don't really understand why we are using protobufs to wrap all messages. This seems to unnecessarily add dependencies. Why not use the same message formats used in reactor-c (and the Python target), opening up the possibility of federates that cross these boundaries? These are well documented here. These functions allow for the use of protobufs for message payloads, which is where I think protobufs will prove particularly useful.

Also, rather than reimplementing from scratch, I suggest reusing the clock sync code in clock-sync.h and clock-sync.c.

[erlingrj]

Protobufs makes it a whole lot easier to build and extend a protocol. The proto-files give you a very nice and clear view of the structure of messages. If we want the multi-lingual federates I think it would be better if everyone adopted protobufs rather than everyone implement a custom binary protocol