gregmedd
commented
5 months ago This change might go too far in removing details. A solution somewhere between #150 and this approach is probably best.
I would propose taking an approach that focuses on defining conceptual components (e.g. "There must be an RpcClient interface...") and behaviors ("...that can invoke methods hosted by an RpcServer").
Another example from #150 was in the passage that defines the error codes returned when invoking an RPC method. Instead of explicitly defining an onError() callback and the values of a UStatus parameter to that, it could be defined as a required behavior:
The RpcClient interface should be capable of producing the following error states when an RPC method is invoked:
- Request Timeout: the request has exceeded the TTL
- Invalid Request: the request message or its parameters were invalid
- Duplicate Request: the request's ID is already in use by an active request
In addition, any errors returned in the form of a response message containing a commstatus other than OK must be surfaced.
The sequence diagrams in #150 were also potentially helpful, although they would also need a similar treatment as described above to focus on behaviors and conceptual components rather than function signatures and concrete classes.
The following change provides the minimal requirements such that language libraries can declare and provide a default implementations of the communication layer (uP-L2) APIs for pub/sub, notification, and RPC messaging patterns.
129