Add (optional) RPC for event-based messages e. g. osi_control and osi_graphics

[globberwops]

Dear all,

osi_control and osi_graphics (and possibly other packages?) will introduce event-based messages into OSI (see project proposal P2022-01 Performance & Packaging WP5 "control messages").
In parallel, there is the ongoing discussion about switching from the current protobuf message description to flatbuffers (see project proposal P2022-01 Performance & Packaging WP1).

Event-based messages would benefit greatly from an RPC (remote procedure call) implementation.
gRPC for example, extends both protobuf and flatbuffers by RPC.

The event-based messages could therefore be defined as gRPC services (example).
The generation of gRPC code could then be made optional in the CMake build, so that users can choose to use plain protobuf/flatbuffers, or additionally the RPC.

On a side note, the original issue also mentions CapnProto, which would add RPC as well.

Regards,
Martin

Martin Stump martin.stump@mercedes-benz.com on behalf of MBition GmbH, Provider Information

[globberwops]

Some more thoughts on the issue:

I understand that OSI only "borrows" the Protobuf IDL, but does not in any way mandate the actual use of Protobuf itself. The same approach could be done re. RPC.

The RPC description, borrowed from gRPC would be layered on top of the plain data description in Protobuf (or possibly FlatBuffers in the future) and kept strictly separate. The build system would then add an option for enabling the RPC layer to not interfere with the current plain data layer.

Regards,
Martin

[globberwops]

Contrary to my last comment, the service definition is actually part of the Protobuf/FlatBuffers grammar, see proto2, proto3, and flatbuffers.

The Protobuf compiler will just ignore the service definition when used without a compiler plugin afaik.
To me, that would be an argument towards putting the service definition into OSI itself as opposed to creating a separate packaging layer, because it is, in fact, implementation agnostic.

@ThomasNaderBMW @pmai @thempen @lemmer-fzi @PhRosenberger @adrianschultz

[PhRosenberger]

Ok, so then the question is, if it would be mandatory or optional to use it, once it would be part of OSI