Would you consider supporting a wasm32-wasi build whose exported functions a host can call, rather than only a _start command module?
Today scriptc build --lib is refused on wasm32-wasi with SC3002, and the compiler notes that the archive/reactor contract is not supported for WASI. What we're after, smallest first:
- Reactor exports on WASI Preview 1. Accept the existing library-mode profile on
wasm32-wasi and emit its declared exports as wasm exports, with _initialize for setup and no _start. The async-free restriction that native library mode already has would be fine for a first version.
- Component Model output (WASI 0.2 /
wasm32-wasip2). Take a WIT world and generate its typed imports and exports, so the output is a component that validates against that world. A documented stopgap would also help, for example reactor module + wasm-tools component new with the preview1 reactor adapter + hand-written WIT.
- Later,
wasi:http outgoing requests on the component target, so fetch can work where the host grants it.
The use case is function-shaped: a host calls handle(input) -> output many times on one instance, rather than running main once. The static tier's small output and lack of an embedded engine make scriptc a very good fit for that, apart from this gap.
This looks related to #265: a WASI reactor would face the same async question, and a host-callable drain export would answer it for both.
Is this on the roadmap, or something you'd accept? We're happy to test preview builds under Wasmtime.
Would you consider supporting a
wasm32-wasibuild whose exported functions a host can call, rather than only a_startcommand module?Today
scriptc build --libis refused onwasm32-wasiwithSC3002, and the compiler notes that the archive/reactor contract is not supported for WASI. What we're after, smallest first:wasm32-wasiand emit its declared exports as wasm exports, with_initializefor setup and no_start. The async-free restriction that native library mode already has would be fine for a first version.wasm32-wasip2). Take a WIT world and generate its typed imports and exports, so the output is a component that validates against that world. A documented stopgap would also help, for example reactor module +wasm-tools component newwith the preview1 reactor adapter + hand-written WIT.wasi:httpoutgoing requests on the component target, sofetchcan work where the host grants it.The use case is function-shaped: a host calls
handle(input) -> outputmany times on one instance, rather than runningmainonce. The static tier's small output and lack of an embedded engine make scriptc a very good fit for that, apart from this gap.This looks related to #265: a WASI reactor would face the same async question, and a host-callable drain export would answer it for both.
Is this on the roadmap, or something you'd accept? We're happy to test preview builds under Wasmtime.