Simplifying the dependency tree

[emilk]

Hello, and thanks for an awesome crate!

I'm interested in replacing the use of reqwest with ehttp.

The advantage is a lot less dependencies. reqwest brings in a huge tree of dependencies, including tokio, while ehttp depends only on the minimal ureq. This in turn translates to faster compile times and smaller binaries.

Would you be open to a PR making such a change?

[podusowski]

Hi Emil, thanks!

Sounds interesting, but last time when I was choosing between two, ehttp didn't support multiple downloads, not sure if that changed? Also, walkers do HTTP cache though http-cache. But if these are addressed, I see no reason not to accept it.

[emilk]

Awesome! Yeah, it will require some work for sure.

What do you mean by "support multiple downloads" though? Downloading multiple files in a single HTTP GET?

[abey79]

A possible avenue might be to split the tile download/cache part from the rendering part, and make the former optionally swappable by a custom implementation.

[jprochazk]

I believe this issue would be a prerequisite to using ehttp in this crate:

• Add support for http caching and keep-alive emilk/ehttp#64

[podusowski]

Downloading multiple files in a single HTTP GET?

Multiple connections. There's a test for it. It's ridiculously slow without it.

[jprochazk]

Hey, I'm currently working on this. The plan is to completely replace reqwest with ehttp, meaning without retaining support for reqwest, tokio, etc., and replacing all async code with equivalent sync code, using threads where needed. Does that sound reasonable?

[podusowski]

using threads where needed.

Well, it's probably a good idea to run io on a separate thread, but walkers have 6 parallel download streams/connections. Starting 6 threads would be a too much bloat in my opinion, so ehttp/ureq would need to support io multiplexing (e.g. via mio).

Unless @emilk and @abey79 are fine with this, then we could put it behind a feature or something.