H-Plus-Time commented on issue #7227:
URL: https://github.com/apache/arrow-rs/issues/7227#issuecomment-2709803598
A couple of clarifications here, on targets:
* wasm32-unknown-unknown
- JS-hosted: wasm-bindgen based, async, streaming work properly (though
control over http protocols, sockets is not possible) in reqwest's wasm
support. By far the most functional.
- not JS-hosted: Considerably more difficult, requiring manual definitions
of extern C bindings; networking and file IO in environments like this were
some of the motivating examples for WASI.
* wasm32-wasi-p1
- not JS-hosted: Network support is explicitly not part of this revision,
this requires explicit host-defined, non-standard fetch equivalents. Generally
this is done through vendor-specific (as in, wasmedge, wasmer, etc) crates or
forks of well-known crates.
- JS-hosted, via wasi polyfills like JCO: requires manual definitions of
extern C bindings (as wasm-bindgen explicitly denies wasi targets).
* wasm32-wasi-p2
- network support (quasi-asynchronous) is present, with the `wstd` crate
as the likely best candidate for papering over the *quasi* part.
* Future, hopefully not too distant: wasm32-wasi-p3
- this is when you'd get actual fully correct behaviour on non-JS-hosted
environments.
In my view, the cases feasible to cover as part of a 1st party default
HttpConnector are:
* JS-hosted wasm32-unknown-unknown. This is what's in my forthcoming PR.
* wasm32-wasi-p2, either host.
Anything outside of that, it should still build (and, importantly, not
contain wasm-bindgen code that would trigger runtime errors), but users are on
their own as far as HttpConnector is concerned.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
