Async/await support

[frol]

Do you have a roadmap as to the async/await-based API? I think it will require migrating to 2018 edition and other breaking changes, so I wonder what the plan is.

[vi]

I'm not sure.

Obviously, it should eventually support tokio > 0.1 (I assume that counts as supporting async/await), but development of this project is sluggish.

Is it proper for rust-websocket to try bashing in tokio 0.2 while still depending on legacy hyper 0.10?

Unless some other contributor steps in, it's unlikely that rust-websocket would support tokio 0.2 this year.

[jhpratt]

@vi I can see what I can do by myself. Would you want to remove the synchronous library? I'd also update hyper, as it seems the sensible thing to do.

[vi]

This all may result in a new websocket library with only partial resemblance of rust-websocket.

If it works well, it may be a good idea to grant the crate name websocket (version 1.x) to it and remane this library to websocket-legacy.

[jhpratt]

Taking that as a yes. I wouldn't jump immediately to a 1.0, but it'll obviously be a breaking change.

[vi]

Would you want to remove the synchronous library?

Not sure. Maybe synchronous version can just use current thread executor under the hood, but still support user-facing API as if it is a pre-async world.

There may be multiple websocket-* crates (low-level functions, async version, sync version that uses async and websocket with just re-exports or gives some additions).

[jhpratt]

Ok, that could certainly work. I'm going to attempt a conversion to async, initially scrapping the synchronous API. If that works, it shouldn't be too difficult to rebuild the sync functions, just using block_on.

[vi]

You may want to use (currently unpublished) websocket-lowlevel crate for Hyper-free part of rust-websocket.

[sdroege]

Is there any update on this, anybody working on this? I could probably spend some time on updating current git master to std futures and tokio 0.2 if there's interest in it, but I won't have time for doing any other refactoring and reorganization of the crate based on the WIP (?) split_in_two branch.

[sdroege]

It seems the split_in_two branch is actually more or less release-ready? In that case I'll base my work on that when I get to it.

[vi]

Recent comments suggest to rename things and maybe further split away futures-independent part.

But anyway if I personally continue something about rust-websocket, it would be that branch. Originally I planned to publish websocket-lowlevel with websocat 2.0, but enthusiasm dwindled and both projects stalled for a while.

[sdroege]

Ok, no worries :) Then I'll start work based on the branch and send you a PR for that once it's working.

Would you want to publish it on crates.io as is then or would you block on splitting it further? From what I understand the goal would be to split into a) a base crate, b) futures support (but not tokio-specific?), c) something to glue things together with hyper?

Also do you want to continue maintaining this project at all or would you be looking for someone to take it over or a co-maintainer?

[vi]

Even if async+edition2018+split version is already ready, I'm going to publish an intermediate version which is already split, but still supports old Rust, old edition and old futures-0.1.

Only the websocket-base crate may end up to be shared between those old and new worlds...

And if to drop old Rust compat then API may be changed drastically as well to be more suitable for hyper 0.12 / http.

[sdroege]

Ok, so I'll start with the port to new futures/tokio based on the split branch and then we'll see where we end up :)

[sdroege]

I have an initial version here https://github.com/sdroege/rust-websocket/tree/tokio-0.2

Covers the lowlevel crate and the tests are passing. I'm cleaning up the tests now and update the docs, then to the highlevel crate.

[sdroege]

And also updated the docs/tests to async/await now. Looks much nicer now if you ask me.