Wasmtime GitHub notifications bot (Oct 19 2022 at 23:59): Wasmtime GitHub notifications bot (Oct 19 2022 at 23:59):Jeffwan opened issue #5079:
Hi community, I am new to WebAssembly and wasi world. I recently have a question on the scope of wasi. Seems wasi-nn and wasi-smartcontract belong to wasi scope. This confuse me a lot. Based on my understanding, only system interfaces like filesystem, networking etc belong to wasi scope so wasi-core totally makes sense to me. Some other packages like crypto works as well because it's part of the core standard library in different languages.
But why nn belongs to wasi but not an ABI? What's the boundary of ABI spec and WASI spec?
(https://github.com/proxy-wasm/spec is a good ABI example, no relation with wasi itself).
Wasmtime GitHub notifications bot (Oct 19 2022 at 23:59):Jeffwan edited issue #5079:
Hi community, I am new to WebAssembly and wasi world. I recently have a question on the scope of wasi. Seems wasi-nn and wasi-smartcontract belong to wasi scope. This confuse me a lot. Based on my understanding, only system interfaces like filesystem, networking etc belong to wasi scope so wasi-core totally makes sense to me. Some other packages like crypto works as well because it's part of the core standard library in different languages.
But why nn belongs to wasi but not an ABI? What's the boundary of ABI spec and WASI spec? WASI itself is ABI, right?
(https://github.com/proxy-wasm/spec is a good ABI example, no relation with wasi itself).
Wasmtime GitHub notifications bot (Oct 20 2022 at 00:02):Jeffwan edited issue #5079:
Hi community, I am new to WebAssembly and wasi world. I recently have a question on the scope of wasi. Seems wasi-nn and wasi-smartcontract belong to wasi scope. This confuse me a lot. Based on my understanding, only system interfaces like filesystem, networking etc belong to wasi scope so wasi-core totally makes sense to me. Some other packages like crypto counts as well because it's part of the core standard library in different languages.
But why nn belongs to wasi but not an ABI? What's the boundary of ABI spec and WASI spec? WASI itself is ABI, right?
(https://github.com/proxy-wasm/spec is a good ABI example, no relation with wasi itself).
Wasmtime GitHub notifications bot (Oct 20 2022 at 00:25):sunfishcode commented on issue #5079:
At the specification level, we tend to talk about APIs, rather than ABIs. WASI is being specified using an Interface Description Language (IDL), which means we can generate a variety off kinds of bindings or ABIs for it, which all represent the same logical interface or API. But that said, yes, you're right, WASI is just an API, or set of APIs, much like other APIs. The main thing that makes WASI APIs special is just that they're developed for standardization within a subgroup of the WebAssembly CG, the standards body for WebAssembly itself.
Concerning the scope of WASI, there isn't anything special about filesystems or sockets or even being part of standard libraries of popular programming languages. We've even moved away from the term "wasi-core" as our understanding has evolved, because many popular use cases don't expect to make use of filesystems or sockets at all, so while it makes sense to have those APIs in WASI, they aren't any more fundamental than other APIs that use cases want.
Ultimately, the scope of WASI is just determined by the set of APIs that are useful to standardize in a standards body. That includes filesystems and sockets and other standard-library functionality, but it includes many other kinds of APIs too. We've recently added many exciting new proposals for things like KV stores, for example.
Wasmtime GitHub notifications bot (Oct 20 2022 at 01:26):sunfishcode commented on issue #5079:
With such a wide scope, it would be a heavy burden for all host implementors to implement all the APIs. So WASI will also standardize what are called Worlds, which are sets of APIs. A "command" World will include the filesystem and sockets and similar APIs, while other Worlds will contain other sets.
Last updated: Oct 23 2024 at 20:03 UTC
