Closed Congyuwang closed 1 year ago
Why not use https://github.com/quininer/futures-rustls?
Well, futures-rustls
is a very good crate for sure. But I still think it is foreseeable that in the future futures-rustls
will have to be manually kept up to date with tokio-rustls
when there are bug fixes and so on, or it will be out of date like async-tls
.
I am not sure whether it is better just so, to have these two repos left separate, or instead, go on as a single code base. The name of the crate perhaps indicates that these two should better be kept separated (why should tokio-rustls
, with tokio in its name, support futures
?)
The futures-rustls crate shares a maintainer with tokio-rustls, so I don't think it will be an issue.
This crate is designed to be light weight wrapper for tokio so I don't think it makes sense to add the additional complexity to support other futures runtimes. I believe there has been some effort somewhere else in the ecosystem to unify this work but I don't believe that that belongs under the tokio org at the moment.
I have forked this repo and made a commit 2fb62eaad5c67e7d6a57f61dca2f116dd7280f61 which added a new feature called "use-futures" that makes this library compatible with
futures interface
and theasync-std
library.The downside of this change is that it involves several blocks of duplicate code due to the different naming of
AsyncWrite
trait, wherepoll_shutdown
is calledpoll_close
infutures
crate. This could make the code base harder to maintain. Moreover, the testing part of this crate can be more cumbersome too, since it should involve testing under two different async frameworks (For the moment, there are still two tests under tokio that I failed to migrate to async-std).The upside of such a change is obviously that it enables users of
futures
inteface to benefit from the update in this repository, and also enables them to contribute to this library too.The diff in Cargo.toml looks like this: