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?
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
featuresto 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-stdorgiousers to benefit from the community and continuous improvement of the library by enabling the 'futures' feature for their choice of backend?