In this PR, we change the client-server interaction protocol around entity state and event subscriptions.
When a client subscribes to server updates, the server allocates some resources in order to keep the subscription working. Unfortunately, we cannot trust the client to close all the subscriptions (because of network errors, page closures, programming mistakes). Thus, the server will eventually close the subscription by itself.
In order to ensure that the subscription is alive as long as the client needs it, the client sends keep-up requests as a way of saying that the client is still there and the subscription is still relevant.
Batch requests
Previously, such requests were sent individually for each subscription. This created an unnecessary load on the server.
From now on, the requests are merged into one, so that the server can handle them in bulk. The same change is applied to the subscription cancellation requests.
Explicit lifespan
Previously, the clients figured out when to send the keep-up requests based on a convention. Now, the subscription and keep-up requests include the time for which the client needs the subscription, and the responses to those requests contain the actual expiration date & time for each subscription. So, the clients may choose to request a longer or a shorter prolongation and the server may choose to fulfill the request or set its own expiration time to a subscription no matter what.
In the current version, the JS client still sends the keep-up requests every n seconds, effectively ignoring the available expiration date & time data. However, now there is a possibility to alter the client lib to work with that data without extra changes to the server lib.
Compatibility
These changes to the protocol are breaking and aren't built to be compatible with the previous protocol. This means that the updates to the client and the server must be done in sync.
There are also breaking changes to the Java server library. In particular, the generic parameters of the subscription servlets and SubscriptionBridge are removed.
The API of the JS client library, on the other hand, is unchanged.
Also, the 3 subscription HTTP endpoints, Subscribe-, SubscriptionKeepUp-, and SubscriptionCancelServlet are not changed. In most cases, the users will not have to alter any code around those servlets. The SubscriptionBulkKeepUpServlet and the SubscriptionCancelAllServlet, introduced in the latest patch to the v1.x, are removed.
In this PR, we change the client-server interaction protocol around entity state and event subscriptions.
When a client subscribes to server updates, the server allocates some resources in order to keep the subscription working. Unfortunately, we cannot trust the client to close all the subscriptions (because of network errors, page closures, programming mistakes). Thus, the server will eventually close the subscription by itself.
In order to ensure that the subscription is alive as long as the client needs it, the client sends keep-up requests as a way of saying that the client is still there and the subscription is still relevant.
Batch requests
Previously, such requests were sent individually for each subscription. This created an unnecessary load on the server. From now on, the requests are merged into one, so that the server can handle them in bulk. The same change is applied to the subscription cancellation requests.
Explicit lifespan
Previously, the clients figured out when to send the keep-up requests based on a convention. Now, the subscription and keep-up requests include the time for which the client needs the subscription, and the responses to those requests contain the actual expiration date & time for each subscription. So, the clients may choose to request a longer or a shorter prolongation and the server may choose to fulfill the request or set its own expiration time to a subscription no matter what.
In the current version, the JS client still sends the keep-up requests every
n
seconds, effectively ignoring the available expiration date & time data. However, now there is a possibility to alter the client lib to work with that data without extra changes to the server lib.Compatibility
These changes to the protocol are breaking and aren't built to be compatible with the previous protocol. This means that the updates to the client and the server must be done in sync.
There are also breaking changes to the Java server library. In particular, the generic parameters of the subscription servlets and
SubscriptionBridge
are removed. The API of the JS client library, on the other hand, is unchanged. Also, the 3 subscription HTTP endpoints,Subscribe
-,SubscriptionKeepUp-
, andSubscriptionCancelServlet
are not changed. In most cases, the users will not have to alter any code around those servlets. TheSubscriptionBulkKeepUpServlet
and theSubscriptionCancelAllServlet
, introduced in the latest patch to the v1.x, are removed.