feat: JsonRpcEngineV2
#6176
feat: JsonRpcEngineV2
#6176
Conversation
rekmarks
force-pushed
the
rekm/json-rpc-engine-rewrite-next
branch
from
f74dff2 to
c393838
Compare
rekmarks
force-pushed
the
rekm/json-rpc-engine-rewrite-next
branch
from
eaa6840 to
df353cf
Compare
This function should never throw; any failures should be the exclusive concern of the error handling layer. Dispatching this error to a remote service also shouldn't hold up request handling.
| export type JsonRpcRequest<Params extends JsonRpcParams = JsonRpcParams> = | ||
| BaseJsonRpcRequest<Params>; | ||
|
|
||
| export type JsonRpcCall<Params extends JsonRpcParams = JsonRpcParams> = |
There was a problem hiding this comment.
Nit: "Call" is a bit of a confusing name for a data structure, because a "call" colloquially also refers to a function invocation.
Could we call this JsonRpcMessage instead?
Alternatively we could stick with the spec's definition, and call this JsonRpcRequest, and rename JsonRpcRequest to.... JsonRpcRequestWithId? NonNotificationJsonRpcRequest? JsonRpcRequestWithResponse? Those are all awful though.
There was a problem hiding this comment.
Yeah, Call isn't great, but Message seems like it should also include responses, which is of course not what we want here. (We use Message in this all-encompassing sense in the Ocap Kernel.)
Ultimately I think it's not unreasonable for "call" as in "remote procedure call" to refer to the message that actually results in some method invocation?
There was a problem hiding this comment.
Even for the "call" in "remote procedure call", that refers to the invocation rather than the request itself. The "call" in "remote procedure call" would be the full interaction, request and response.
There was a problem hiding this comment.
Good point about "message" being inclusive of responses though.
JsonRpcInboundMessage is not bad 🤔
Closes #6088
WIP.
Explanation
References
Changelog
Checklist