Stream: subscriptions
Topic: websockets signal
Brian Reinhold (May 05 2019 at 10:58):
My understanding is that when using websockets the server only sends the subscription id when an event happens. Then the client must go and fetch the given resource. I do not think that is sufficient. The server also needs to send the logical id of the received resource that signaled the event. Think of this situation. I subscribe to all Observations with subject=Patient/123. Then somewhere out there patient 123 uploads 100 measurements taken the past two day from a glucose meter. How am I as a subscription client able to ascertain which measurements these are? There may be several other measurements already on the server, perhaps taken the same day (say BP measurements) and my subscription client was not connected.
IF the server sent at least the logical id of the resource that triggered the event, I would have an unambiguous means to obtain the correct resource.
Grahame Grieve (May 05 2019 at 11:16):
the idea is that the client just re-runs the search. The semantics are clear: the results of this search just changed
Jenni Syed (May 05 2019 at 13:40):
If we go the event direction, we may lose that semantic
Grahame Grieve (May 05 2019 at 14:06):
I'd hope that we add a different approach and not lose that, personally
Jenni Syed (May 05 2019 at 14:09):
For Brian, something we talked about a bit at the table is that he could re-run the query, but use _lastUpdated to avoid getting the whole data set
Jenni Syed (May 05 2019 at 14:10):
The challenge is determining what _lastUpdated value to use
Last updated: Apr 12 2022 at 19:14 UTC
