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
Is it possible at the moment to implement the pattern used with websites like Slack, Discord, GitHub, etc.. of getting initial state via a HTTP GET request, and then the state object returned has a monotonic version number which is then sent back to the server to establish a websocket connection and all updates since that version are sent down the websocket to allow the client to reconstruct the current state without having to send the whole object everytime it changes.
I've managed to implement the server side logic using some shared mutable server state and mutex, but the client side logic is posing a lot more difficulty since it requires combining the right hooks in the right way, (use_websocket, use_future, use_resource, etc..). I think it would be easier to implement if it was possible to manually drive a websocket connection in a use_future loop rather than using use_websocket which doesn't specify when it attempts to reconnect, and can't be restarted manually on a resync. Although it was possibly mentioned that that would be possible here: #4954 (comment).
Is there another way of using perhaps tungstenite instead of use_websocket, I would appreciate if anyone could point to some examples using this approach.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Is it possible at the moment to implement the pattern used with websites like Slack, Discord, GitHub, etc.. of getting initial state via a HTTP GET request, and then the state object returned has a monotonic version number which is then sent back to the server to establish a websocket connection and all updates since that version are sent down the websocket to allow the client to reconstruct the current state without having to send the whole object everytime it changes.
I've managed to implement the server side logic using some shared mutable server state and mutex, but the client side logic is posing a lot more difficulty since it requires combining the right hooks in the right way, (
use_websocket,use_future,use_resource, etc..). I think it would be easier to implement if it was possible to manually drive a websocket connection in ause_futureloop rather than usinguse_websocketwhich doesn't specify when it attempts to reconnect, and can't be restarted manually on a resync. Although it was possibly mentioned that that would be possible here: #4954 (comment).Is there another way of using perhaps
tungsteniteinstead ofuse_websocket, I would appreciate if anyone could point to some examples using this approach.Many thanks.
Beta Was this translation helpful? Give feedback.
All reactions