You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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?The text was updated successfully, but these errors were encountered: