Design discussion

[zeenix]

This would be a follow-up from the discussion that started here. I'd like to discuss the basic approach taken here and how we can make the API work nicely before I finish the implementation, move this under smol-rs and release.

One problem with the simple async_channel aggregation approach is how one of the receiver in the chain might have a channel that's full or closed and Sender::{try_send, send} failing because of that, and even worse, some of the receivers getting the message while other don't. The latter is easy to fix as we can just not immediately error out on sending but rather send to everyone we possibly can and throw the error at the end. However, how do we combine errors from multiple channels and how useful is this to the user?

3 options come to mind:

1. We make this an explicit async_channel::Sender aggregator, where user explicitly add and remove Sender instances (that they create themselves). While this is simple, it also means this crate basically just provides a send loop and hence not useful.

2. Add API in async_channel to create leaky channels (that is, when channel is full, the last message is popped to make room) and use that here. However, what to do about a closed channel?

3. Don't use async_channel at all and just try to create an API similar to that of tokio's broadcast channel.

[zeenix]

Ok, seems there already was a WIP project for this so I'll archive this project.