Any plan to add async support ?

[gembin]

Why is this feature valuable to you? Does it solve a problem you're having?
I think futures ecosystem and async/await have already stabilized

Describe the solution you'd like

Describe alternatives you've considered

Additional context

[wfraser]

I've been playing with an async prototype of this crate for a long time now, and yes, while the async ecosystem has progressed greatly in the past few years (my first attempt was written with futures 0.1, before async/await existed, and that was NOT fun), it's still not satisfactory to me yet.

The current reasons I'm holding off on making that change:

• It adds significant complexity, which gets pushed onto users.
  • It requires a lot more dependencies, increasing build times.
  • All users would be required to pull in a runtime, increasing dependencies yet further, even if they just want a simple blocking API.
    • Just take a look at the dependency tree for reqwest, even compiled in its blocking mode, which claims to be a "simple" HTTP client. Compare with ureq, which is not async and is actually simple.
• Futures have to take ownership over their arguments, which results in a lot of unnecessary copying.
  • For example, consider that most API calls will want to be wrapped in a retry loop. With the current code, you can reference one set of arguments repeatedly. With async, you have to clone them each time through the loop, even if you never end up needing to retry.
  • This is especially painful with upload endpoints, where the current code lets you just pass in a byte slice, but the async code needs an owned buffer. Those buffers may be quite large.
• AsyncRead / AsyncWrite is still immature, and much of the ecosystem doesn't work with it yet, which makes writing a HTTP client agnostic interface problematic.
  • Hyper, the most prominent async HTTP client, doesn't work with AsyncRead/AsyncWrite yet.

If you want to take a peek, my current development branch is at https://github.com/wfraser/dropbox-sdk-rust/tree/async2. Fair warning: it gets squashed and force-pushed often, otherwise rebasing becomes impossibly complicated.

For now, if you want to use this crate in an otherwise fully async project, you can use tokio::task::spawn_blocking.

[gembin]

Thanks for the thorough explanation! I agree it will certainly add complexity. I will take a look at the async branch, thanks!