snapview / tokio-tungstenite

Future-based Tungstenite for Tokio. Lightweight stream-based WebSocket implementation
MIT License
1.88k stars 236 forks source link

Implement `Source` from `mio` for `WebSocketStream` as a feature #228

Closed keksbg closed 2 years ago

keksbg commented 2 years ago

Quick and dirty commit to implement the Source trait from mio to be able to poll on the WebSocketStream struct as a separate feature under mio. Did it because I was going to use it in my own code that uses mio to poll but I wasn't able to find an easy way to wrap WebSocketStream.

If there's an easy way to do this in user code please do let me know (even though I don't think it's a bad idea to implement it at the dependency level, considering it's also called tokio-tungstenite), as the compiler does not like me implementing traits, which are defined outside of my crate, for types that are defined outside of my crate. Either one has to be defined in the same crate, per E0117.

daniel-abramov commented 2 years ago

I'm not sure there is any valid use case for it. How would you use it?

If you're using Tokio, you usually don't use the mio simultaneously since mio is something that Tokio relies upon internally. You won't be able to trivially implement the Source like that for the whole stream since the underlying stream is unlikely to implement Source (tokio::TcpStream does not).

While you could potentially pass a stream that implements Source, such a stream won't be useful within Tokio runtime. If you're willing to use mio::Source, you're likely to be implementing your own runtime in which case you might want to work with tungstenite directly instead of tokio-tungstenite. But chances are, you don't really want to do this and rely on Tokio instead 😉 (in which case the implementation of Source becomes irrelevant).

keksbg commented 2 years ago

I see, thank you for the explanation.