Viceroy should be able to execute a C@E Wasm program from the command line as just a one-shot without requiring an external process to send it a request. This would enable the use of Viceroy to run test suites that are compiled to a wasm32-wasi target with the C@E Wasm imports, such as those produced by cargo test --target wasm32-wasi.
The wasmtime CLI could be a useful model here. In a Rust project, I am able to run my test suite in both native code and Wasm simply by adding a .cargo/config:
[target.wasm32-wasi]
runner = "wasmtime"
In addition to providing the one-shot execution model, wasmtime also hooks up stdio and such to make it look like the Wasm program is executing within the host environment. That's pretty different from the headless daemon approach that Viceroy currently supports.
Finally, we'll need to figure out what to do about hostcalls. For the purposes of running a test suite, we'd get a lot of value even if the C@E hostcalls didn't do all that much. There are many useful tests to write that don't even use the C@E APIs, and many more that only would need, e.g., the ability to read and write to a body. Eventually I could imagine wanting some more sophisticated behavior even in a unit test, but since the daemonized version is already there I don't think the needs are as pressing.
Viceroy should be able to execute a C@E Wasm program from the command line as just a one-shot without requiring an external process to send it a request. This would enable the use of Viceroy to run test suites that are compiled to a
wasm32-wasitarget with the C@E Wasm imports, such as those produced bycargo test --target wasm32-wasi.The
wasmtimeCLI could be a useful model here. In a Rust project, I am able to run my test suite in both native code and Wasm simply by adding a.cargo/config:In addition to providing the one-shot execution model,
wasmtimealso hooks up stdio and such to make it look like the Wasm program is executing within the host environment. That's pretty different from the headless daemon approach that Viceroy currently supports.Finally, we'll need to figure out what to do about hostcalls. For the purposes of running a test suite, we'd get a lot of value even if the C@E hostcalls didn't do all that much. There are many useful tests to write that don't even use the C@E APIs, and many more that only would need, e.g., the ability to read and write to a body. Eventually I could imagine wanting some more sophisticated behavior even in a unit test, but since the daemonized version is already there I don't think the needs are as pressing.