Open 1tgr opened 1 year ago
As described, this change causes disruption to current async and synchronous users of websocket-lite:
async_connect
to connect
Alternatively, websocket-lite could contain the synchronous code, and we could have a new tokio-websocket-lite for the async code:
_async
suffix from method callstokio
, futures_util
and other async crates are no longer needed
I'd like to get some opinions on splitting the websocket-lite crate into two halves:
On #230, @Gelbpunkt requested to remove the synchronous functions but I said they were useful: non-futures-based code is easier to optimise, and works fine provided you can dedicate a thread to a connection.
On #204, @jjl suggested that we could remove the tokio dependencies for apps that only use the synchronous code.
I propose that the websocket-lite and websocket-lite-sync crates have an identical API: for example, both crates expose a method
ClientBuilder::connect
, instead of separateconnect
andasync_connect
methods.The websocket-codec crate gains a
tokio
feature, which causes it to impl theEncoder
andDecoder
traits from tokio_util. The crate gets its ownEncoder
andDecoder
traits, regardless of thetokio
feature.Rather than copying and pasting the source code into two crates, I was considering using the im and im-rc crates' trick to compile two crates from one source tree.