Skip to content
This repository has been archived by the owner on Jan 14, 2022. It is now read-only.

Stream multiplexing (API change) #121

Open
Gargron opened this issue Apr 3, 2020 · 2 comments
Open

Stream multiplexing (API change) #121

Gargron opened this issue Apr 3, 2020 · 2 comments
Labels
post-1.0 Feature to add after releasing v1.0.0

Comments

@Gargron
Copy link
Member

Gargron commented Apr 3, 2020

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.

@codesections codesections added the post-1.0 Feature to add after releasing v1.0.0 label Apr 5, 2020
@codesections
Copy link
Contributor

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.

@codesections codesections mentioned this issue Apr 5, 2020
@codesections
Copy link
Contributor

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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
post-1.0 Feature to add after releasing v1.0.0
Projects
None yet
Development

No branches or pull requests

2 participants