3 ms·

That's true, PATCH would solve that specific writing aspect of the problem, but there is still the issue that each user would not know that the other user has c

That's true, PATCH would solve that specific writing aspect of the problem, but there is still the issue that each user would not know that the other user has changed another property; we need some kind of server push mechanism to inform users that the underlying data has changed. Also, if users update one field at a time, it's more expensive to have one HTTP request per field (considering the HTTP headers overhead and potentially having to open a new connection) rather than using one WebSocket frame per update.

jungturk 8y ago
Server-sent events might be a good fit here. Note that SSE belongs to the content layer (HTML) rather than the transfer layer (HTTP) so its specifically about notifications to active clients about content changes to resources they're observing. Here's someone describing their experience with it: https://medium.com/axiomzenteam/websockets-http-2-and-sse-5c24ae4d9d96 https://medium.com/axiomzenteam/websockets-http-2-and-sse-5c...
- jondubois 8y ago
  The fact that the SSE connection is unidirectional makes it impossible to quickly and efficiently detect disconnection from the server-side; this costs extra in terms of performance. Also, SSEs make it essentially impossible to implement features like real-time user online/offline presence and automatic renewal of authentication tokens (without closing the previous real-time/SSE connection).
  - jungturk 8y ago
    Good points about the limitations - SSE certainly won't be useful for lots of scenarios and you might prefer resorting to traditional approaches in those scenarios (in lieu of or in concert with an SSE channel).
icebraining 8y ago
there is still the issue that each user would not know that the other user has changed another property; we need some kind of server push mechanism to inform users that the underlying data has changed If the data occasionally changes, you can just respond to the update request with a 409 Conflict reporting the problem and allowing the user to fix it. If it's changing so fast that it requires real-time updates, the user can't probably keep up either, so you should re-think your mechanism.

jungturk 8y ago

Server-sent events might be a good fit here. Note that SSE belongs to the content layer (HTML) rather than the transfer layer (HTTP) so its specifically about notifications to active clients about content changes to resources they're observing. Here's someone describing their experience with it: https://medium.com/axiomzenteam/websockets-http-2-and-sse-5c24ae4d9d96 https://medium.com/axiomzenteam/websockets-http-2-and-sse-5c...

jondubois 8y ago
The fact that the SSE connection is unidirectional makes it impossible to quickly and efficiently detect disconnection from the server-side; this costs extra in terms of performance. Also, SSEs make it essentially impossible to implement features like real-time user online/offline presence and automatic renewal of authentication tokens (without closing the previous real-time/SSE connection).
- jungturk 8y ago
  Good points about the limitations - SSE certainly won't be useful for lots of scenarios and you might prefer resorting to traditional approaches in those scenarios (in lieu of or in concert with an SSE channel).

icebraining 8y ago

there is still the issue that each user would not know that the other user has changed another property; we need some kind of server push mechanism to inform users that the underlying data has changed If the data occasionally changes, you can just respond to the update request with a 409 Conflict reporting the problem and allowing the user to fix it. If it's changing so fast that it requires real-time updates, the user can't probably keep up either, so you should re-think your mechanism.