A client side application, such as the atomic-data-browser front-end, should be informed when a Resource is updated server side. This will enable things like live collaboration in Documents.
In this browser, this means opening a Websocket. Through this Websocket, messages can be exchanged both ways. I think we'll need these types of messages:
Commit, which describes how a particular resource has been modified. These can go both ways.
Subscribe, which tells the server that the client will want to receive updates when a specific resource is updated.
Unsubscribe, which tells the server that the client is no longer interested in update for a resource.
I think a decent endpoint is /ws.
The messages themselves will be JSON text messages. I think these, too, should be serialized as if they were Atomic Data resources. So even Subscribe and Unsubscribe should be instances of their respective classes.
A client side application, such as the
atomic-data-browser
front-end, should be informed when a Resource is updated server side. This will enable things like live collaboration in Documents.In this browser, this means opening a Websocket. Through this Websocket, messages can be exchanged both ways. I think we'll need these types of messages:
/ws
.Subscribe
andUnsubscribe
should be instances of their respective classes.