Spec disallows multiple subscriptions per channel per client, but reference implementations allow it
jtbandes opened this issue · comments
The spec says:
A client may only have one subscription for each channel at a time.
However, our reference implementations allow this by keeping a mapping from channel id to multiple subscription ids for each client:
ws-protocol/python/src/foxglove_websocket/server/client_state.py
Lines 23 to 25 in c883a5f
It would also be good to document the role of subscription ids. Without that, these extra set of identifiers seem like unnecessary complexity.
I am also skeptical that the features for which subscription ids were conceived could be added without breaking the protocol. In that case, it might be better to keep the protocol simple until we have a clear idea of what those features will look like.
That's a fair point, however, removing subscription ids would also mean breaking the protocol at this point. This v1 protocol has been shipped in production for quite a while.
That's correct. Removing the subscription id now will break the protocol. We only have two choices now:
- Remove the wording about 1:1 mapping between channel and subscription id from the spec, or
- Make it official by removing the support for multiple subscription ids from the reference implementations
Option 1 is confusing right now without the context because it does not make sense for the server to send the same message multiple times to the same client.
I am also skeptical that the features for which subscription ids were conceived could be added without breaking the protocol.
What features would that be for instance? I don't fully get the purpose of subscription IDs yet, it seems like they were added to make client implementations easier?
One of the disadvantages of subscription IDs is, that we have to construct individual messages per client which is rather expensive (copying message data multiple times instead of just once)
