You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the speedrun.com API we use the exact same code. Instead of copy pasting it, we should make it available via some crate that anyone can use. One possibility is to usptream it into the http-client crate, which already has a similar, but really buggy implementation. However I consider those maintainers fairly toxic, so I'm not sure if I really want to upstream the code into that repository.
Additionally for the event stream we are introducing an async WebSocket implementation which we likely also want to upstream somewhere. The http-client crate may not be what we want for that as it doesn't have any WebSocket capabilities and we would need to provide one for their native backends. However for the native implementation we use tokio-tungstenite and the http-client maintainers have personal issues with the tokio maintainers. So that will cause even more problems.
I really just want to make a gloo-http crate (gloo is the JS APIs but as idiomatic Rust, so gloo-http would be ideal), but I'm not sure if making such a crate without having talked to the gloo maintainers beforehand is a good idea.
The text was updated successfully, but these errors were encountered:
It is pretty obvious now that the way to go is to create a PR to gloo to add the code as the gloo-http crate. People seem to be on board with that and crates like reqwest and http-client can then depend on gloo-http for their http implementation.
CryZe
changed the title
Possibly upstream the WebAssembly HTTP Client implementation into some crate
Upstream the WebAssembly HTTP Client implementation as gloo-http
Dec 18, 2019
For the speedrun.com API we use the exact same code. Instead of copy pasting it, we should make it available via some crate that anyone can use. One possibility is to usptream it into the http-client crate, which already has a similar, but really buggy implementation. However I consider those maintainers fairly toxic, so I'm not sure if I really want to upstream the code into that repository.
Additionally for the event stream we are introducing an async WebSocket implementation which we likely also want to upstream somewhere. The http-client crate may not be what we want for that as it doesn't have any WebSocket capabilities and we would need to provide one for their native backends. However for the native implementation we use tokio-tungstenite and the http-client maintainers have personal issues with the tokio maintainers. So that will cause even more problems.
I really just want to make a gloo-http crate (gloo is the JS APIs but as idiomatic Rust, so gloo-http would be ideal), but I'm not sure if making such a crate without having talked to the gloo maintainers beforehand is a good idea.
The text was updated successfully, but these errors were encountered: