use features to make tokio-rustls compatible with `futures` interface
#115 enable futures users to contribute and use tokio-tls crate.
I hope to see something like this merged at some point, but this implementation has a very big flaw: the use-futures feature is not additive, so it breaks the the ability to use tokio if any of the project's dependencies decide to use futures instead.
I see. So how to make this additive? Perhaps it'll need to separate most of the code from any of these async framework (e.g. tokio, futures), and then kind of providing additive adaptors to different framework? I don't know. Will this possibly making it additive?
This implementation has some other problems too. For example, for futures users, because the currently implementation needs BufRead which is from tokio::io, resulting in needing to compile the complete tokio library just for this single struct.
But, it still seems to me that this problem of making it compatible with both tokio and non-tokio users is worth trying.
I think we'd need separate structs for the tokio and the futures implementation, and then have features for enabling tokio or futures. Anyway I was just leaving a drive-by comment. Considering that the crate name starts with tokio- I'm not even sure it makes sense for it to support futures.
tokio-rustls has moved to https://github.com/rustls/tokio-rustls. Please reopen your PR there if you're still interested.