Relationship with WebIDL bindings

[littledan]

My understanding is that WASI uses a calling convention that makes sense for direct use with languages like C. At the same time, there's ongoing work on WebIDL to make it into a practical, language-neutral API binding layer, with WebIDL bindings.

I'm curious why WebIDL doesn't meet the needs for WASI. When APIs for new capabilities are exposed, what is the advice for API designers, in terms of choosing between WebIDL and WASI-style APIs? What would be the relationship with WebIDL if WASI comes to the Web? If WASI is a path towards exposing new capabilities, like mmap, to the Web, how should those be accessible from JavaScript?

[sunfishcode]

We're currently using C-style bindings because when we started, "WebIDL bindings" was still called "host bindings" and had many open design questions. To my knowledge, WebIDL bindings is still under development, and there are still discussions about what features should be included in an "MVP" release, and it's not yet clear whether that will be sufficient for WASI. That said, I agree that as WebIDL bindings becomes more stable, we should ask whether it suits our needs.

When APIs for new capabilities are exposed, what is the advice for API designers, in terms of choosing between WebIDL and WASI-style APIs?

This sounds like a question for the folks working on WebIDL bindings. I've now opened WebAssembly/interface-types#28 to ask it.

[lukewagner]

[Edit: oops, raced with Dan writing my somewhat more verbose response.]

This is an important question; thanks for bringing it up! I'll give one possible answer that I've had in mind, but happy to discuss alternatives.

So as background, while WASI is currently defined in terms of C signatures, which ultimately get compiled down to mostly i32s in the ABI, the plan is to reframe WASI in terms of reference types well before the first official release. In doing so, the current C signatures wouldn't be abandoned/deprecated, instead they could be re-defined as being automatically derived from the underlying reference-typed WASI signatures, along with a canonical glue-code library that used table.get/table.set to map between i32 indices and reference types at runtime, similar to what wasm-bindgen does today. Thus, while there would be both C-style and reference-style entry points, the former would be defined in terms of the latter, avoiding meaningful spec duplication while saving C folks the headache of figuring out how to smuggle reference types and table.get into LLVM. (The reason for starting with only the C signatures is that this works in wasm MVP which is more-widely supported and thus more readily experimented with atm.)

Given all that, the question is: what role do WebIDL and WebIDL Bindings play in reference-typed WASI?

So a first observation is that most of the reference types that WASI would want to define to replace all its current i32-backed types (e.g., __wasi_fd_t) would correspond to WebIDL interfaces. But WebIDL Bindings don't do anything special for Interface types; one either passes an anyref or, once they are in wasm, an imported reference type, and both cases would just use the trivial as binding operator. If this is all we cared about, WASI signatures could simply be defined in terms of importable types and functions.

So the question is: would WASI signatures have any use for any of the "interesting" WebIDL types that have non-trivial binding operators. The most motivating example I can think of is strings: it would be useful if WASI could accept a string without:

• forcing all callers to create a reference to a GC string (hurting C-style languages)
• forcing all callers to allocate strings in linear memory (hurting GC'd languages)
• adding two signatures for every string-taking API (one for refs, one for linear memory)
• forever committing to a single encoding (unless UTF-8 Everywhere!, I dunno)

From these requirements, it does seem useful to have a single abstract string reference-type (used e.g. for the path of __wasi_path_open and using a binding operator like utf8-str to allow C to pass a pointer to linear memory without copying.

Working backwards, this could suggest defining WASI's reference-typed interfaces in terms of WebIDL so that it was natural to take advantage of WebIDL Bindings. While there will be a lot of stuff in WebIDL that probably WASI doesn't want to use, one could imagine restricting WASI to a WebIDL subset to ease the burden on non-Web bindings implementations. So that's one possible future, but it's hard for me predict this far out; I think it depends on how things develop with WebIDL Bindings, WASI and the surrounding ecosystem.

What would be the relationship with WebIDL if WASI comes to the Web? If WASI is a path towards exposing new capabilities, like mmap, to the Web, how should those be accessible from JavaScript?

I don't see WASI as a path towards exposing new capabilities on the Web; those would need to be proposed as Web standards and go through the normal process. Instead, where possible, WASI APIs would be mapped to Web APIs (e.g., using wasm adaptor modules--implemented in terms of WebIDL Bindings, of course :).

[jgravelle-google]

In principle I think there's significant value from an API perspective to be able to describe a schema rather than an ABI, and in that context using something like a WebIDL DOMString to represent the concept of strings, and binding that into a given language/runtime is a nice way to model it. This also allows for a decoupling of interface + implementation: for example a Rust implementation of a WASI method can use Rust strs, and a C++ user on could call it with a const char*.

Whether WebIDL is a good fit for this type of interface binding, I'm not sure. I for one wouldn't mind making WebIDL less web-specific (ditto making WebAssembly less web-specific), but I don't know enough about the constraints to speak with confidence. In particular I'm extremely interested in having some more-rich binding layer in place, especially one that's less browser-specific. If WebIDL fits too poorly to standardize on in a JS-less environment (which I don't find too unlikely, to be clear), I'd love to hear specific shortcomings for potential future designs in this abstract binding space.

[littledan]

Thanks for all the thoughtful discussion here. I am no longer worried about any kind of overlap/mismatch.

[sunfishcode]

The question here is answered; please re-open or file new issues if there are any further questions!