You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a user, I would like to be able to efficiently subscribe to a range of rows at the end of an updating table. Currently, this requires a 3-way dance:
Server notifies client that the table's size has changed
Client asks the server to move the viewport to the "new" end
Server computes and sends a new effective viewport and snapshot to the client
This introduced extra message traffic and latency for viewport changes.
Alternatively, with a "reverse viewport" subscription, the server will know that the client wants to stay subscribed to rows starting from the end of the table as position 0, and counting up towards the first row of the table. This will allow the server to simply skip straight to step 3, advising the client of its new effective viewport and snapshot, with no explicit request from the client.
We have already added the necessary request message support in Barrage 0.4.0. This ticket is to cover the implementation on the server side and in the Java reference client.
The text was updated successfully, but these errors were encountered:
As a user, I would like to be able to efficiently subscribe to a range of rows at the end of an updating table. Currently, this requires a 3-way dance:
This introduced extra message traffic and latency for viewport changes.
Alternatively, with a "reverse viewport" subscription, the server will know that the client wants to stay subscribed to rows starting from the end of the table as position 0, and counting up towards the first row of the table. This will allow the server to simply skip straight to step 3, advising the client of its new effective viewport and snapshot, with no explicit request from the client.
We have already added the necessary request message support in Barrage 0.4.0. This ticket is to cover the implementation on the server side and in the Java reference client.
The text was updated successfully, but these errors were encountered: