David Ramos
David Ramos
Sure, I'd welcome a PR to do that
First off, thanks for all the work maintaining this excellent crate! This issue came up in the `oauth2` (https://github.com/ramosbugs/oauth2-rs/pull/230) and `openidconnect` (https://github.com/ramosbugs/openidconnect-rs/pull/127) crates, which support WASM but initially panicked until...
Reading #1164 and #1472, it seems like the motivation was to support WASM targets without the JS interface. Option 2 would break compilation for those targets when the default features...
Sorry, this turned into a more involved PR than I expected!
no worries, thanks!
> Although I didn't have the intention to expose async outside of the client, I kind of like the approach here. > Would you be so kind as to run...
also, is the objection to adding `async_std` due to the additional dependency cost, or is it specifically about mixing the tokio and async_std _runtimes_? it feels like runtime-agnostic primitives like...
I think given the issues around dropping runtimes at various points in the code, the runtime-agnostic approach would be preferable. I'll try to incorporate that change :-)
looks like the [`async_executors`](https://crates.io/crates/async_executors) crate provides some nice adapters for different runtimes to be able to leverage the [`futures::task::Spawn`](https://docs.rs/futures/0.3.12/futures/task/trait.Spawn.html) trait. the commit I just pushed takes in an `Arc` and...
btw I just open sourced an OpenTelemetry crate built on top of this crate! https://github.com/ramosbugs/opentelemetry-honeycomb-rs