-
Notifications
You must be signed in to change notification settings - Fork 0
Description
This seems contentious despite me personally thinking it's fine so I'm opening this issue to discuss it.
The proposed solution is to add a websocket packet which notifies clients of the current user count.
Benefits to adding an event
If clients frequently use the data, they either have to make many requests or deal with stale data:
- Making many requests will increase the required bandwidth, though this can be mitigated with caching if the data doesn't change frequently.
- If the data is stable, stale data is not so consequential. When this could matter is a significant surge in users, changing the value dramatically.
By adding an event, the server can decide how frequently it wants to update this information.
This allows it to save bandwidth where needed.
Websocket packets are more efficient for bandwidth in general than an HTTP packet, especially if the client has to poll more frequently than the value changes.
Downsides to adding an event
The server does not know when the client wants to use the data.:
- Clients which do not want this data are forced to receive it anyway.
- Clients cannot dictate to the server how frequently they need the data, meaning they will either get it more or less frequently than they desire.
Servers already have mechanisms for controlling bandwidth - rate limits.
Polling an unchanging value has very little overhead - HTTP implements effective caching of requests.
Adding an event adds complexity in the client, server, and the specification.