Notes on RPC and message type harmonization

[pavel-kirienko]

If the named topic development continues roughly along the lines outlined in this post: https://forum.opencyphal.org/t/rfc-zero-configuration-cyphal-with-named-topics/2376/7?u=pavel.kirienko, then it would be desirable to reflect the unification of topics with RPCs in the DSDL language design. Specifically, right now we have two distinct categories of types: message types and RPC types. The former will stay as-is, while the latter may need to be made a subset of message types, where the request part becomes just an ordinary message definition, and the response part becomes the optional response type of the message.

For example, an ordinary message definition implies that no response type is defined for it:

# Message.1.0
float16 value
@sealed

While messages that prescribe a response (whether mandatory or optional) will contain the additional section at the end:

# Message.1.0
float16 value
@sealed
---
# Message.Response.1.0
float16 response_value
@sealed

[thirtytwobits]

This seems somewhat aesthetic in effect for the IDL but with meaninful impact to implementations. While I appreciate the symmetry I'm not sure it's worth the effort to adapt to this change.

What's the goal here? To round over rough edges or to support optional responses?

[pavel-kirienko]

@thirtytwobits We need some mechanism in place to define response data types such that they are associated with the corresponding request type (i.e., message type). I think it is desirable to have a way to tightly couple them at the language level. We could introduce a completely new syntax for this, but as we discussed at the last call, we need to be careful with new features to manage complexity growth. If we accept the general direction I proposed for named topics, then in v1.1. there will be no need to keep the old RPC services, hence we can recycle the existing syntax for response data types.