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
{{ message }}
This repository has been archived by the owner on Jan 14, 2022. It is now read-only.
A planned development in upstream Mastodon is to multiplex multiple streams through a single connection. For example, if a user has 10 columns with different hashtags in their web UI, that's currently 10 separate websocket connections. That's a waste of resources. Instead, the dynamic nature of websockets could be used to subscribe and unsubscribe from specific streams. The return format would then need to be enhanced to say which stream a given message belongs to.
The text was updated successfully, but these errors were encountered:
Thanks for the heads up. Flodgatt should be able to accommodate this, and I already have some ideas for how it should do so.
The exact Flodgatt implementation will obviously depend some on how it is implemented upstream. Is there a tracking issue for this change upstream? I searched the tootsuite/mastodon issues and didn't see one – my apologies if I just missed it.
Would the idea be to support both the current single-channel streams and multiplexed streams though the existing v1 API rather than splitting off a v2 for mutiplexed streams? Both seem possible, and I can think of pros/cons to both approaches.
To support this change, Flodgatt will need to read incoming messages from the WebSocket (which it currently does not, to save CPU). Making this change will also allow Flodgatt to close its WebSocket connections more promptly, which will help resolve a rare/minor UI bug: currently, if a client closes a WebSocket (because the user navigated away from that timeline) and then establishes a new connection to the same endpoint (because the user navigated back to that timeline) and does so before Flodgatt has fully closed the first connection, then the UI will display a "load more" button even though no messages were lost. This happens very rarely, but it will be nice to ensure it can never occur.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
A planned development in upstream Mastodon is to multiplex multiple streams through a single connection. For example, if a user has 10 columns with different hashtags in their web UI, that's currently 10 separate websocket connections. That's a waste of resources. Instead, the dynamic nature of websockets could be used to subscribe and unsubscribe from specific streams. The return format would then need to be enhanced to say which stream a given message belongs to.
The text was updated successfully, but these errors were encountered: