Open drahnr opened 4 years ago
As a start, I agree that Future-based API similar to what reqwest 0.10 introduced would be nice (with ::blocking
namespace for consumers that want to delay migration).
I am not that familiar with how to make the library parametric on arbitrary http library (I think I could handle implementing the most common ones through feature flags), if you have any links explaining that, I would appreciate that.
Generally speaking, if you can write a decoder that can yield / pause decoding of protocol related structs and expose that, it would already be enough. It's fairly simple to subsequently write explicit or implicit futures around it. But it might be just enough to provide an async API in this use case
While a sync API is a nice starting point, it might make more sense to implement a generalized parser which then can be used with arbitrary http libraries or at least migrate to an async API and provide sync wrappers providing compat with todays APIs.