Using wasmtime-api with wasmtime-wasi and wasmtime-interface-types

[skyne98]

Hi there, awesome work you are doing here guys!

However, I have a small question: is wasmtime-api compatible with crates such as wasmtime-wasi or wasmtime-interface-types in any way?
Right now, it seems that for it to work the wasmtime_api crate will have to explicitly support WASI via a flag in the configuration or something for the Instance to create its handle via the function provided as an alternative by the wasmtime-wasi crate. Even in this case, it looks like it would be a much better idea to include a completely optional wasi_config: Option<WasiConfig> field in the configuration for the engine, that will include pre-opened dirs, etc.

Including WASI support seems pretty straighforward, if doing it this way and not trying to engineer a more generic solution like guys at Wasmer did here.

What do you think?

[skyne98]

So, as far as I can see, the binary code for wasmtime includes all the necessary parts for both of those things. Why not include all of them into wasmtime-api and then use it in the binary instead of having specific code for WASI module initialization, etc?

[yurydelendik]

It is a possibility. The embedding API (wasmtime_api) was mostly shaped by wasm-c-api. It does not stop us to include wasi and interface-types. We are working to bring these three concepts closer, see e.g. #364, #540 or #509 , which will influence further design for the API.

As you mentioned above, at this moment a user/embedder can put all pieces together, e.g. by following the src/bin/wasmtime.rs example. Is your question simply about the reducing amount of the boiler place code developers have to write?

[skyne98]

Mostly - yes. I think it might be better for you, guys, to dictate such things by API crates for the sake of other developers not doing it in less than efficient ways. Also, such a crate being in a good state will allow the ecosystem to build up quicker around Wasmtime, attracting more developers, but I am starting to speculate.

[alexcrichton]

The long-term vision going forward is that general users should use the wasmtime crate (what used to be wasmtime-api) and the API there is pretty complete as-is and is being refined in #708. We'd like to add WASI support there and plan to support interface types there as well so I'm going to close this in favor of those issues.