Rust binding for this proposal

[q82419]

Hi there, here's from WasmEdge runtime.

Take the WASI-NN proposal for example, there's rust binding generated from the witx format.
Developers can use the witx-bindgen to generate the rust binding easily.
With this generated library, developers can call the WASI proposal APIs in rust and compile into WASM.

But currently the WASI proposals provides the wit format, which can be compiled into component model.
For the other WebAssembly runtimes, supporting the component model is not so easy and quickly due to its complexity.
To support this proposal, we should have:

• The ABI documentation in WASM, especially the host function parameter and return types in WASM.
• The rust binding to this proposal, in order to generate the test WASM invoking the host functions of this proposal.

Unfortunately, this WASI-WebGPU proposal doesn't provide the information for the API doc, which is the most important to implement this proposal.
Can you help to provide the rust binding and API doc so that developers can try to compile the WASM files without component?
Thanks!

[MendyBerger]

Hi, thanks for filing this issue!

Just trying to understand your exact needs, is this what you'd like us to replicate?
https://github.com/bytecodealliance/wasi-nn/blob/main/rust/src/generated.rs

[q82419]

Hi, thanks for filing this issue!

Just trying to understand your exact needs, is this what you'd like us to replicate? https://github.com/bytecodealliance/wasi-nn/blob/main/rust/src/generated.rs

Hi,

Sure! With the generated Rust binding like that, developers can create their guest program in Rust and compile into core WebAssembly module without component model.
It'll be much more convenient to test and support this proposal.
As you see, almost no runtime except Wasmtime supports component model proposal.

Thanks!

[pchickey]

The witx bindings provided by wasi-nn are for historical reasons because the proposal existed prior to wit. The wasi-nn team is coming up with their plan to retire those bindings, because maintaining a separate set is a considerable burden, and splits the ecosystem among two incompatible ABIs.

My understanding was that wasmedge has a component implementation in progress. I think our efforts, collectively, would be much better spent helping y’all get your component implementation completed rather than require proposals such as wasi-webgpu to come up with a representation and implementation of their spec in the legacy and incompatible witx ABI.