0.6 release? about tokio-tungstenite

[daniel-abramov]

We thought about the release with the current state from master, but there is still one thing we're waiting for: tokio-tls. There is a patch in Cargo.toml of tokio-tungstenite, without this patch the crate won't compile due to the tokio-tls dependency which currently uses the old version of native-tls. We hope that tokio-tls will get released soon with the new native-tls dependency (tokio-rs/tokio-tls#43), at that point we can remove the [temporary] patch from our Cargo.toml and release a new version of tokio-tungstenite.

[agalakhov]

Yes. It was actually planned for the previous week but this was not done due to other urgent tasks.
Do you have any special wishes for 0.6? Any functionality you're missing?

[seanmonstar]

Not that I can think of for this specific library.

If asking, in tungstenite proper, I might suggest that Message uses something like Bytes instead of Vec<u8> or String, to reduce the amount of allocations of copies needed. But I'd suggest that just for performance, I'm not exposing the actual Message enum to users, specifically to allow the internal buffer type to be changed without affecting them.

[ParadoxSpiral]

When do you plan to release the new version to crates.io?
I've switched to this crate from websockets because this is much nicer, but don't want to push the move until it's not a git dep anymore.

[zargony]

I'm too using tokio-tungstenite for websocket communication instead of the websocket crate because tokio-tungstenite's is nicer and easier to use.

Speaking of tokio_tls.. What do you think about making the AutoStream type public?
That'd be helpful for working with the resulting websocket item of connect_async. To handle the resulting websocket (e.g. keep it in a struct or pass it to a function), I need to give it's exact type. However, I can't use its type WebSocketStream<AutoStream<S>>, since AutoStream isn't public. So I always end up using the full type WebSocketStream<StreamSwitcher<TcpStream, TlsStream<TcpStream>>>, which also means that I need to add tokio_tls as a direct dependency to get the StreamSwitcher type, which is a little unconvenient.

[agalakhov]

I even feel that AutoStream should be a separate crate. There are many cases when the same code could either use TLS or not, and this has nothing to do with WebSocket. We had to reinvent many wheels for Tungstenite.

[zargony]

In a separate crate or maybe in tokio_tls. However, the name AutoStream could be a little confusing since it sounds like the stream would automatically detect TLS. Maybe something like OptionalTlsStream would be better if used outside of tokio_tungstenite.

[agalakhov]

Totally agree.

[daniel-abramov]

Or maybe even something more general like StreamType / NetworkStream or something like that.

[daniel-abramov]

UPD. We're not waiting for tokio-rs/tokio-tls#43 anymore. According to the latest information, Carl has suggested to merge the following pull request: tokio-rs/tokio-tls#45.

Once the changes are merged and published, we can use the version of tokio-tls from crates.io.

The PR was merged and tokio-tls 0.2 has been published.

[daniel-abramov]

Yes, I think we're ready for release now.

ping @agalakhov

@zargony the AutoStream changes and other small things might be delivered in the upcoming patch version improvements, unless you want to send a pull request before @agalakhov publishes a release ;)

[agalakhov]

Version 0.6.0 released.