📝 added documentation for websocket RPC-Framework #2

ninanonemon commented 2026年05月18日 22:15:14 +02:00

No description provided.

sigmasternchen commented 2026年05月18日 22:39:25 +02:00

Hmm, it feels both a bit over-engineered and also a bit too "loose". Having a request-based system will complicate the socket-handling a lot since the component that handled messages needs to keep track of message IDs, and which component/subject is supposed to handle that specific request/response. I'm assuming whether or not a specific request expects a response depends on the action of the request? In that case the websocket component additionally needs to be aware of the which actions require responses, so the response messages can be parsed correctly.

I wonder if you could reduce the coupling between the different request-emitting/response-receiving components to the websocket handling component by splitting requests that require a response from requests that don't. I've seen a pattern in the past that uses "call" vs "event" instead of "request". "call" expect a response, while "event" doesn't. "updateScoreboard" would be an "event" because it does not have any returned data and doesn't require callbacks.

Alternatively: If you want to make sure that all messages definitely arrive, then don't make responses optional. Right now the document says "maybe", but there is an argument to be made that no requests should be async - everything needs an acknowledgement response. I think I refer the first option but both would drastically reduce the complexity of the protocol implementation I think.

Hmm, it feels both a bit over-engineered and also a bit too "loose". Having a request-based system will complicate the socket-handling a lot since the component that handled messages needs to keep track of message IDs, and which component/subject is supposed to handle that specific request/response. I'm assuming whether or not a specific request expects a response depends on the action of the request? In that case the websocket component additionally needs to be aware of the which actions require responses, so the response messages can be parsed correctly. I wonder if you could reduce the coupling between the different request-emitting/response-receiving components to the websocket handling component by splitting requests that require a response from requests that don't. I've seen a pattern in the past that uses "call" vs "event" instead of "request". "call" expect a response, while "event" doesn't. "updateScoreboard" would be an "event" because it does not have any returned data and doesn't require callbacks. Alternatively: If you want to make sure that all messages definitely arrive, then don't make responses optional. Right now the document says "maybe", but there is an argument to be made that no requests should be async - everything needs an acknowledgement response. I think I refer the first option but both would drastically reduce the complexity of the protocol implementation I think.

ninanonemon commented 2026年05月18日 23:06:53 +02:00

@sigmasternchen wrote in #2 (comment):

There are definitely messages where I want to be sure that they have arrived, for example if a penalty was submitted.

The reason why I wrote maybe, is that the response to a call can be a "error" too. I think I should clarify that.

Adding "event" messages is a good Idea. In rollerderby/scoreboard clients can subscribe to "events", something which would be easier to model with an "event" message type.

@sigmasternchen wrote in https://codeberg.org/ninanonemon/lucyboard/pulls/2#issuecomment-15211916: There are definitely messages where I want to be sure that they have arrived, for example if a penalty was submitted. The reason why I wrote maybe, is that the response to a call can be a "error" too. I think I should clarify that. Adding "event" messages is a good Idea. In rollerderby/scoreboard clients can subscribe to "events", something which would be easier to model with an "event" message type.

ninanonemon commented 2026年05月18日 23:41:06 +02:00

@sigmasternchen what do you think now? I added a event message type.

@sigmasternchen what do you think now? I added a `event` message type.

Reason: