|
|
|
|
|
by hntrl
428 days ago
|
|
> sending a RequestID to the server so that you get request/response cycles isn't weird nor beyond the pale. To me the sticking point is what if the "response" message never comes? There's nothing in the websocket protocol that dictates that messages need to be acknowledged. With request/response the client knows how to handle that case natively > And the websocket browser API is nicer to work with than, say, EventSource. What in particular would you say? |
|
Kind of like how you also need to implement app-layer ping/pong over websockets for keepalive even though tcp already sends its own ping/pong. -_-
As for EventSource, I don't remember exactly, something always comes up. That said, you could say the same for websockets since even implementing non-buggy reconn/backaway logic is annoying.
I'll admit, time for me to try the thing you pitch in the article.