This is a great crate. The state of affair of async-tls is problematic. Its update to rustls 0.20 is still not released, whereas users are providing continuous feedback to tokio-tls.
It seems to me that futures-rustls is compatible with either tokio-tls and async-tls. Is it possible to use rust features to provide a different configuration for different needs of backends.
For example, is it possible to use features = ['tokio', 'futures'] where the default feature is 'tokio' so that tokio users won't feel any change, while enabling async-std or gio users to benefit from the community and continuous improvement of the library by enabling the 'futures' feature for their choice of backend?
I really like this crate. The code is much better than async-tls. It just feels a little bit awkward that it might need to be manually kept up to date with another crate (tokio-tls) in the future.
This is a great crate. The state of affair of async-tls is problematic. Its update to rustls 0.20 is still not released, whereas users are providing continuous feedback to tokio-tls.
It seems to me that futures-rustls is compatible with either tokio-tls and async-tls. Is it possible to use rust
features
to provide a different configuration for different needs of backends.For example, is it possible to use
features = ['tokio', 'futures']
where the default feature is 'tokio' so that tokio users won't feel any change, while enablingasync-std
orgio
users to benefit from the community and continuous improvement of the library by enabling the 'futures' feature for their choice of backend?