WebSocket request/response model

[ekuiter]

Right now, the server receives WebSocket messages from the client and may answer these (usuall with the updated feature model), but requests and responses are not linked in any way. Of course, this is the intended use of WebSockets. Still, sometimes a client-server model like this would be useful, especially for error handling.

For example: If the user wants to rename a feature, but the name is invalid (e.g., already used), the server currently answers with an error message that is not traceable to the request, so the client has to show the error message out of context (not in the feature renaming dialog, but in a generic "error messages" area). If the client could trace the response (error message) to the request (feature rename), the dialog could stay open and attach the error message to the input field. This is a less annoying user experience.

As this pattern will occur more often (with error messages, of course, and maybe only with error messages), we should solve this generally (most likely by introducing a TCP-like sequence number). We may then promisify requests on the client (e.g., sendMessage(...).then(handleRes, handleErr)) and handle errors in the local editing context.

[ekuiter]

This is not needed now that we have the Clojure kernel. For regular operations, no error message will need to be returned (instead, conflict resolution information is sent). Elsewhere, we can just use global error messages. The complexity is not worth it.