`Socket.io` vs. raw websockets

[lars-reimann]

Is your feature request related to a problem?

Socket.io is a protocol for bidirectional communication. It uses websockets internally when available, but can also fall back to other technologies. Compared to raw websockets, we

• lose some flexibility for our protocol design,
• gain a well-tested, rigid framework for our protocol,
• get extra features like disconnection detection or automatic reconnection.

Desired solution

• Investigate whether the switch to Socket.io is worth it.
• Replace flask-sock by flask-socketio (the VS Code extension also has to be updated).
• Use the built-in test client to test the server. This may also fix #18.

Possible alternatives (optional)

No response

Screenshots (optional)

No response

Additional Context (optional)

No response

[WinPlay02]

I don't think a switch to socketio would be needed in the near future.

• Disconnections could be detected in the extension by adding callbacks to the onclose event of the existing websocket connection.
• Automatic reconnection is already (partially) implemented in the extension, by trying to spawn a new runner if the existing one crashed or became unusable. This could easily be expanded with the before mentioned disconnection detection.
• I don't think the switch would fix issue #18, as subprocesses would still be required.
• I don't think the fallback option (HTTP polling) is desirable (and needed). In a local environment, we should always expect websockets to work (so there is little need for fallback options).

Though I very much agree on the easier testing argument.

[lars-reimann]

All valid points. Let's talk about this on Thursday.

[lars-reimann]

Apparently, the W3C is also working on another means for bidirectional communication, called WebTransport. Socket.io v4 recently added support for this, allowing us to use WebTransport without further changes to our code, once it's widely available.