Currently with the jsii-runtime
, whenever the runtime is started it emits a HelloResponse
message. This makes sense to ensure that the runtime version is compatible with the client. However, the way it is currently implemented means that the protocol layer (either implicit or explicit) has to specially handle this message.
The typical flow when interacting with the jsii-runtime
is essentially a request/response cycle, for every response you get you had to first make a request. However, the hello message is different, it is a response without a correlating request, which means that the protocol layer has to handle a request-less response for just this one single message.
It seems like it'd be sane to instead make it just another command that can be invoked. So instead you'd end up doing something like:
> {"api": "hello"}
< {"hello": "[email protected]"}
We could mimic the command structure even more, and move the {"hello": "..."}
into a {"ok": {"hello": "..."}}
structure.
This would allow clients to treat every interaction with the jsii-runtime
as a request/response cycle, eliminating the need to special case the protocol. Besides the obvious compatibility issues, the biggest issue I see with this is that because this is required to be stable, if we change the framing or format in some way, this command would have to be excluded from that, so you'd end up special casing the parsing of the response for this command instead.
Because of the nature of this command, it would have to be stable for basically forever, but the rest of the protocol can evolve as required.
This would also allow some minor amount of startup optimization for implementations that bundle a jsii-runtime
, because the bundling will prevent version drift that this seeks to eliminate.
Thoughts?