3 ms·

I agree about what your concerns about complexity, but the way I see what we're encapsulating is almost entirely essential. To draw analogies with native binari

I agree about what your concerns about complexity, but the way I see what we're encapsulating is almost entirely essential. To draw analogies with native binaries: - Wasm is a (virtual) instruction format for programs to be compiled into (think: x86). - Wasm Components are a container format and type system that wrap Core Wasm instructions into typed, hermetic binaries and libraries (think: ELF). - WASI is a reserved namespace for a collection of standardized Wasm component interfaces (think: POSIX header files). To reach our goal of having shared, portable binaries that aren't locked into any one vendor we need all three. A standard instruction set, standard calling convention, and standard syscalls. Wasm Components and WASI might not be necessarily be perfect, but at a minimum they're targeting the right scope. And that carries essential complexity.

MisterTea 2y ago
> A standard instruction set, standard calling convention, and standard syscalls. This sounds like an OS like user space to run atop WASM similar to POSIX. Standards are good but my hope is the design is well thought out.
apitman 2y ago
I agree that some things are essential, and there's value in specifications. The question is how likely is the current tragectory to follow what happened with browsers? The major players are the same, which is concerning. Then there's early signs from the specs themselves. Why do we need wasi-sockets and wasi-http? Why not only specify wasi-sockets and let HTTP be implemented optionally by libraries for apps that need it? Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation? Because that's how you end up in the situation where the "user agent" with majority market share starts gutting ad blockers. I'm not saying I'm predicating this will happen with WASM or even think it's very likely. I don't know enough to have a real opinion on that. I'm just saying I really really don't want it to happen.
- yoshuaw 2y ago
  > Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation? The big change going from WASI 0.1 to WASI 0.2 is that we decoupled the calling convention (Wasm Components) from the actual syscall APIs (WASI). That enabled us to make the various syscall APIs modular and composable. Because CDN functions probably shouldn't know about TCP; and CLI applications probably don't care about blob storage. And now they don't need to. Take a look at the WASI Proposals page [1] for an overview of all WASI APIs. [1]: https://github.com/WebAssembly/WASI/blob/main/Proposals.md https://github.com/WebAssembly/WASI/blob/main/Proposals.md
  - apitman 2y ago
    So basically the reasoning is that things like wasi-http wouldn't be mandatory for a compliant implementation? That would be good. Thanks for the link. I was trying to find a single page with everything listed.
- coldtea 2y ago
  >The question is how likely is the current tragectory to follow what happened with browsers? What happened to browsers? Few vendors implementing them? There are still 3 major vendors supporting an open source runtime or two (Google and MS on Blink), and a good open implementation (Mozilla). Better than 20 competing engines, does anybody miss IE's own engine? And with WASM it's way easier for multiple implementations to be written, if need be, as it's a language runtime. These have 1/100th the scope of a browser (which is 99 other very hard to implement things PLUS a WASM runtime). >The major players are the same, which is concerning. Then there's early signs from the specs themselves. Why do we need wasi-sockets and wasi-http? Why not only specify wasi-sockets and let HTTP be implemented optionally by libraries for apps that need it? Because "let third parties define and write basic libraries" (and sockets and http are very basic) has been a disaster every time. You get a fragmented ecosystem, several popular libs fighting it out, and users either stay away or suffer the consequences. At least with an official spec implementations will be compatible, and we'll get some reference one.
- 2y ago

MisterTea 2y ago

> A standard instruction set, standard calling convention, and standard syscalls. This sounds like an OS like user space to run atop WASM similar to POSIX. Standards are good but my hope is the design is well thought out.

apitman 2y ago

I agree that some things are essential, and there's value in specifications. The question is how likely is the current tragectory to follow what happened with browsers? The major players are the same, which is concerning. Then there's early signs from the specs themselves. Why do we need wasi-sockets and wasi-http? Why not only specify wasi-sockets and let HTTP be implemented optionally by libraries for apps that need it? Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation? Because that's how you end up in the situation where the "user agent" with majority market share starts gutting ad blockers. I'm not saying I'm predicating this will happen with WASM or even think it's very likely. I don't know enough to have a real opinion on that. I'm just saying I really really don't want it to happen.

yoshuaw 2y ago
> Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation? The big change going from WASI 0.1 to WASI 0.2 is that we decoupled the calling convention (Wasm Components) from the actual syscall APIs (WASI). That enabled us to make the various syscall APIs modular and composable. Because CDN functions probably shouldn't know about TCP; and CLI applications probably don't care about blob storage. And now they don't need to. Take a look at the WASI Proposals page [1] for an overview of all WASI APIs. [1]: https://github.com/WebAssembly/WASI/blob/main/Proposals.md https://github.com/WebAssembly/WASI/blob/main/Proposals.md
- apitman 2y ago
  So basically the reasoning is that things like wasi-http wouldn't be mandatory for a compliant implementation? That would be good. Thanks for the link. I was trying to find a single page with everything listed.
coldtea 2y ago
>The question is how likely is the current tragectory to follow what happened with browsers? What happened to browsers? Few vendors implementing them? There are still 3 major vendors supporting an open source runtime or two (Google and MS on Blink), and a good open implementation (Mozilla). Better than 20 competing engines, does anybody miss IE's own engine? And with WASM it's way easier for multiple implementations to be written, if need be, as it's a language runtime. These have 1/100th the scope of a browser (which is 99 other very hard to implement things PLUS a WASM runtime). >The major players are the same, which is concerning. Then there's early signs from the specs themselves. Why do we need wasi-sockets and wasi-http? Why not only specify wasi-sockets and let HTTP be implemented optionally by libraries for apps that need it? Because "let third parties define and write basic libraries" (and sockets and http are very basic) has been a disaster every time. You get a fragmented ecosystem, several popular libs fighting it out, and users either stay away or suffer the consequences. At least with an official spec implementations will be compatible, and we'll get some reference one.
2y ago