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 Mar 25, 2021. It is now read-only.
If a user doesn't manually remove disconnected clients they'll continue to accumulate in Room.clients. To me this is unacceptable. I think this justifies reviving an old idea of mine, to have an optional output channel for expired clients.
Disconnected clients wouldn't be stored inside Room at all; depending on Option they would be either Dropped or emitted on a disconnected_client_tx channel.
I've been trying to figure out what features should go on Room directly. A related idea is to have a client_insertion_rx channel for asynchronously adding clients #14 . These two channels would start to really up the complexity of Room.
Design exploration
Room
Room removes from Room.clients immediately when disconnect is detected.
impl Stream for Room emits a disconnected Client as Err
As-yet-unnamed type we'll call ChannelledRoom.
Presumably provides the same Future-creating methods as Room. A trait could enforce this. The various future types could be parametric over that trait if the different logic could be kept to impl Sink + Stream for ChannelledRoom.
impl Sink + Stream for ChannelledRoom takes Err(Client)s and emits them on disconnected_client_tx. I can drop irritating Error: Clone requirements if this then returns something less precise in Err.
Tradeoffs
The memory leak must go. The library must be safe by default.
We still need to get ahold of disconnected clients, as many network services will want to reestablish connections/do logic with that.
This ChannelledRoom is only strictly necessary for easy combinator code. Custom futures can simply insert new clients and trivially use returned errors.
ChannelledRoom would make the library more complicated. It leads in a promising direction, as a generalised ReconnectingRoom might then be possible, but we're talking quite complex genericism here.
The value of non-custom-futures code is largely appealing/simple examples. I don't think it would be sensible very often to directly use Room.
* `Room`'s `Stream + Sink` impls now emits `Client` as `Err` when one disconnects. #20
* `Status` type removed as it no longer made sense. Methods moved onto `Client`.
If a user doesn't manually remove disconnected clients they'll continue to accumulate in
Room.clients
. To me this is unacceptable. I think this justifies reviving an old idea of mine, to have an optional output channel for expired clients.Disconnected clients wouldn't be stored inside
Room
at all; depending onOption
they would be eitherDrop
ped or emitted on adisconnected_client_tx
channel.I've been trying to figure out what features should go on
Room
directly. A related idea is to have aclient_insertion_rx
channel for asynchronously adding clients #14 . These two channels would start to really up the complexity ofRoom
.Design exploration
Room
Room
removes fromRoom.clients
immediately when disconnect is detected.impl Stream for Room
emits a disconnectedClient
asErr
ChannelledRoom
.Future
-creating methods asRoom
. A trait could enforce this. The various future types could be parametric over that trait if the different logic could be kept toimpl Sink + Stream for ChannelledRoom
.impl Sink + Stream for ChannelledRoom
takesErr(Client)
s and emits them ondisconnected_client_tx
. I can drop irritatingError: Clone
requirements if this then returns something less precise inErr
.Tradeoffs
ChannelledRoom
is only strictly necessary for easy combinator code. Custom futures can simply insert new clients and trivially use returned errors.ChannelledRoom
would make the library more complicated. It leads in a promising direction, as a generalisedReconnectingRoom
might then be possible, but we're talking quite complex genericism here.Room
.Decisions
Room
must stop storing disconnectedClient
. Remove that immediately. Stop storing disconnected clients in Room. #21ChannelledRoom
is a nice-to-have. Something to think about after av0.1.3
.The text was updated successfully, but these errors were encountered: