ghanemabdo
commented
8 years ago Proposal for a notification service that extends the current pubsub mechanism implemented in Gold. It should cover the following areas: 1) How clients show/revoke interest to track changes in a particular resource (Subscribe/Unsubscribe). 2) The way a server should track changes on a watched resource. 3) How a server should respond to an action happened on a resource a client is subscribed to (Publishing events).
1) Subscription/Unsubscription:
client applications register to listen to particular events that occur on a resource. The event can be:
- POST/PUT a new resource (append),
- Patching a resource (update) or
- Deletion of a resource (delete).
subscription is done via websocket with the pod as following:
"sub https://example.com/container/resource [append/update/delete] [persistent]"
if no event is mentioned, the client is registered for all events happening on the resource.
"persistent" here means the server should keep tracking the resource even after the websocket opened with the client is closed.
unsubscription is done by sending the following websocket message to the pod:
"unsub https://example.com/container/resource [append/update/delete]"
If no event is mentioned, the client is unregistered from all events happening on the resource.
In case an application is subscribed to a resource with "persistent" option and the websocket is closed without submitting unsub request, next time when the user subscribes to the same resource, a list of all events happened on this resource since last time the websocket connection is closed is posted to the client with the "ack" message (maybe it could be separated in a special message pulling changes on this resource instead of attaching changes to the ack). To stop receiving and tracking changes on a resource, the client must submit unsub websocket message for this container to the pod (Still thinking about a way to stop persistent subscriptions in case of buggy apps shouldn't overwhelm the server).
2) Server tracking events:
depends on the status of the client. If the client is:
- Online: which means the websocket is open. Whenever the server receives a request with an event registered on a resource, the server automatically sends a "pub" message to all registered clients.
- Offline: which means the websocket is closed. It depends on the server implementation. Currently, I think of a timestamp system that tracks the time the websocket is closed and remembers the time that every event happens on the resource. Something like a log resource of all events happened after the websocket is closed. This way the server has records of all events happening on a set of resources.
3) Event notification:
When an append/update/delete event occurs, a websocket message is sent from the pod to the client including the following parameters:
- The keyword "pub",
- The URI of the resource triggered the action,
- The action type append/update/delete
the notification should look like this:
"pub https://example.com/container/subcontainer/resource1.ttl [append/update/delete]"
for "persistent" subscriptions, the "ack" message may look like:
"ack https://example.com/container/subcontainer\n
https://example.com/container/subcontainer/resource1.ttl append\n
https://example.com/container/subcontainer/resource1.ttl update\n
https://example.com/container/subcontainer/resource1.ttl delete
...
"- Advantages of this extension:
1) Applications relying on rapid changes in a container can get resource-level updates about these changes instead of container-level updates which adds so much pain in tracking the changed resources. 2) Filter events a client app is interested in (append/update/ delete). 3) Tracking offline updates via persistent subscriptions.
- Expected problems:
1) Multiple clients registered to the same resource. 2) Buggy apps make persistent subscription to resources and don't unsubscribe. What's the scenario for terminating a persistent subscription? 3) Subscriptions to resources having frequent changes. Traffic will be enormous. Is there a way to limit overwhelming client apps with a lot of messages? like for example batching events periodically.
sandhawke
bblfish
CxRes
kjetilk
We need to find a way for a server to be able to declare interest in a resource changing in some way. This would require each resource to point to a resource where a client can subscribe to changes in the resource, perhaps using SPARQL, with a pointer to a container to send notifications to when those changes have been triggered. Probably requires some form of authentication of the user, to verify that the notification box is the right one.