For background, WASI 0.1 is one interface: a smaller POSIX. Translating POSIX's low-level ABI concepts into WASM is enough for this. WASI came out of WASM's goal of portability, and 0.1 makes WASM portable across POSIX systems.
WASM and WASI aim to support other embeddings. WASI 0.2 introduces an interface for HTTP servers and clients, aimed at cloud/edge. Currently Docker images (on an OS) get used here, but POSIX, even small POSIX, is bloat. WASI 0.2 plans a range of other interfaces for embedding WASM e.g. IOT, so that even without POSIX, you still have portable standards, in your preferred language.
HTTP is a high-level idea. HTTP libraries in any language are never about writing binary to TCP sockets, they're about requests and responses. Depending on sockets would miss the point of leaving POSIX behind. A smaller, loosely-coupled API surface gives both sides more freedom. The runtime can work with the system, the language can work with its users, and the tooling can generate minimal glue that links them together.
Why define WASI APIs with an abstract interface rather than a rigid binary one? Because it follows the spirit of WASM's existing goals: low-level when needed for performance, and high-level whenever it makes WASM simpler to target, embed or reason about. That's why WASM has low-level assembly instructions yet high-level structured control-flow. It's also why WASI uses types appropriate for the API in question (e.g. files in the POSIX interface, responses in HTTP) yet translates them to binary glue when linking real hosts and guests.
Lin Clark's 2019 article[1] raises an issue that comes with low-level interfaces:
But if a function takes or returns anything besides numbers, things get complicated. You can either:- Ship one module that has a really hard-to-use API that only speaks in numbers… making life hard for the module’s user.- Add glue code for every single environment you want this module to run in… making life hard for the module’s developer.
Clark argues WebAssembly is the right abstraction level to solve this issue in an efficient yet ergonomic way. Frankly, if your WASM module written in Go wants to talk to your host in Java, I don't see why that needs to involve C bindings.
The Component Model falls out of WASI as a bonus. WASI needs to interoperate modules with their embeddings. From there WASI may as well (Lin Clark puts it) "interoperate all the things".
WASM and WASI aim to support other embeddings. WASI 0.2 introduces an interface for HTTP servers and clients, aimed at cloud/edge. Currently Docker images (on an OS) get used here, but POSIX, even small POSIX, is bloat. WASI 0.2 plans a range of other interfaces for embedding WASM e.g. IOT, so that even without POSIX, you still have portable standards, in your preferred language.
HTTP is a high-level idea. HTTP libraries in any language are never about writing binary to TCP sockets, they're about requests and responses. Depending on sockets would miss the point of leaving POSIX behind. A smaller, loosely-coupled API surface gives both sides more freedom. The runtime can work with the system, the language can work with its users, and the tooling can generate minimal glue that links them together.
Why define WASI APIs with an abstract interface rather than a rigid binary one? Because it follows the spirit of WASM's existing goals: low-level when needed for performance, and high-level whenever it makes WASM simpler to target, embed or reason about. That's why WASM has low-level assembly instructions yet high-level structured control-flow. It's also why WASI uses types appropriate for the API in question (e.g. files in the POSIX interface, responses in HTTP) yet translates them to binary glue when linking real hosts and guests.
Lin Clark's 2019 article[1] raises an issue that comes with low-level interfaces: But if a function takes or returns anything besides numbers, things get complicated. You can either: - Ship one module that has a really hard-to-use API that only speaks in numbers… making life hard for the module’s user. - Add glue code for every single environment you want this module to run in… making life hard for the module’s developer. Clark argues WebAssembly is the right abstraction level to solve this issue in an efficient yet ergonomic way. Frankly, if your WASM module written in Go wants to talk to your host in Java, I don't see why that needs to involve C bindings.
The Component Model falls out of WASI as a bonus. WASI needs to interoperate modules with their embeddings. From there WASI may as well (Lin Clark puts it) "interoperate all the things".
[1]: https://hacks.mozilla.org/2019/08/webassembly-interface-type...