break a lot of stuff to try and see what needs to be done for no_std

[brandonros]

I'm just doing this to be silly/for fun. Not sure if I will finish it. It's kind of therapeutic... Not even sure if I'm doing it the right way... Is there a tool that can migrate this for us? :D

[algesten]

Yeah. This is sort of the direction I think we need to explore.

I would opt for disabling stuff like gzip compression and the default transport behind the std flag.

It's also worth looking at the ureq-proto PR to see which imports I made and where I put them. I'm thinking of vec! and the order of imports that I try to keep consistent.

The heavy reliance on io::Read in body is a problem. Wonder if there is a
no-std crate to help with that?

Great start!

[brandonros]

@algesten how about now in its current state, do you think it's something I could hand off to you / that you plan to take a deeper look into? I don't have a super pressing need for it, just thought it'd be fun :)

[algesten]

Sure! Thanks!

[brandonros]

@algesten not sure if this is of any value: https://github.com/hyperium/http/pull/732/files

I was going to try to achieve std + no_std in the same repo in this toy client I made for fun here: https://github.com/brandonros/http_client

but I didn't realize AsyncRead + AsyncWrite trait are heavily tied to std

nrc/portable-interoperable#5

rust-lang/wg-async#23

rust-lang/futures-rs#860

I also don't think fetch (what no_std wasm will boil down to) actually needs async, so it sounds like overkill all around on my end and something you can probably avoid by being nice and simple with sync only

[algesten]

Interesting! Yeah, async in no_std is a can of worms.