4 ms·

> "Component model interfaces always support link-time interposition." > > Like WTF does this mean? The repo tells me nothing Directly above the sentence you

> "Component model interfaces always support link-time interposition." > > Like WTF does this mean? The repo tells me nothing Directly above the sentence you quoted: "Interposition in the context of WASI interfaces is the ability for a Webassembly instance to implement a given WASI interface, and for a consumer WebAssembly instance to be able to use this implementation transparently. This can be used to adapt or attenuate the functionality of a WASI API without changing the code using it." > and I've still yet to see a clear write-up about what WASI is. In the same document: [0] > WTF is wit? The first link in that document ("Starting in Preview2, WASI APIs are defined using the Wit IDL.") is [1]. > I click on "legacy" and I see preview0 and preview1, which are basically unreadable proto-specs. The README for the legacy directory [2] clearly explains what they are. > Where's a single well-written WASI spec? "Development of each API happens in its own repo, which you can access from the proposals list." [3] > Whatever WASI is doing, I don't like it. Clearly not - you've gone out of your way to ignore all of the documentation that answer your questions. > And neither does AssemblyScript team apparently The AssemblyScript team have a bone to pick with WASI based on their misunderstanding of what WASI is for (it is not intended for use on the web) and WASI's disinterest in supporting UTF-16 strings. You can see for yourself in [4]. [0]: https://github.com/WebAssembly/WASI/tree/main#wasi-high-level-goals https://github.com/WebAssembly/WASI/tree/main#wasi-high-leve... [1]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md https://github.com/WebAssembly/component-model/blob/main/des... [2]: https://github.com/WebAssembly/WASI/blob/main/legacy/README.md https://github.com/WebAssembly/WASI/blob/main/legacy/README.... [3]: https://github.com/WebAssembly/WASI/blob/main/Proposals.md https://github.com/WebAssembly/WASI/blob/main/Proposals.md [4]: https://github.com/WebAssembly/WASI/issues/401 https://github.com/WebAssembly/WASI/issues/401

SnowProblem 3y ago
None of this is excusable. Tell me what your project does in clear English. "WASI is a standard for 50 functions you can call to do systems-level things from your WASM code. Here they are." Done. I don't care about wit/witx. I don't care the repo being in transition. I don't want to read about interposition or components or capabilities. I don't want to see your copy-pasta goals from WASM (which aren't clear for WASI). You're an API. Show me the API.
- jedisct1 3y ago
  https://wasix.org/docs https://wasix.org/docs may be what you are looking for. The WASI section documents WASI as it is implemented today. But since then, WASI pivoted and has become an umbrella for multiple projects. This is not just an API any more, and at the moment, the documentation on the WASI site and repositories is for WASI developers, not for developers using WASI. So if you didn't follow the whole thing, it is indeed be very hard to understand. The stack is complicated. But the ultimate goal of the project is to actually make it easier for developers to use wasm, without having to worry about all these details. It's essentially about adding dynamic linking to wasm. The dynamic libraries embed the function prototypes, so that calling functions with the wrong type will cause a link error. That requires the definitions of every type of function, and WIT, WAI and WITX are domain-specific languages to do that. Right now, WebAssembly is limited to static linking. It works very well, even across languages, but types aren't automatically checked. Actually, they are, but only using the primitive types available in WebAssembly. Here, the goal is to support something very close to the Rust type system. The proposal also allows restricting every library to their own memory region. So, a buggy or malicious library can only mess with its own data, not with the rest of the application.
  - skybrian 3y ago
    Interesting. This seems almost like an object-oriented system where the objects can be large libraries written in different languages. Do libraries have a lifecycle? Can you instantiate multiple instances of them?
  - SnowProblem 3y ago
    A million times better. Looks like this comes from the Wasmer team.
- Philpax 3y ago
  > Tell me what your project does in clear English. Okay. "Define a set of portable, modular, runtime-independent, and WebAssembly-native APIs which can be used by WebAssembly code to interact with the outside world. These APIs preserve the essential sandboxed nature of WebAssembly through a Capability-based API design." That's the first goal. > I don't care about wit/witx. I don't care the repo being in transition. I don't want to read about interposition or components or capabilities. Everything you've just mentioned is relevant to people implementing the spec, given its wide scope and nature. It is not reducible complexity. It is not a drop-in replacement for POSIX (i.e. it is not "a standard for 50 functions"); it goes beyond that, and aims to provide a secure and modular way to interact with the system where capabilities can be delegated or reduced.

SnowProblem 3y ago

None of this is excusable. Tell me what your project does in clear English. "WASI is a standard for 50 functions you can call to do systems-level things from your WASM code. Here they are." Done. I don't care about wit/witx. I don't care the repo being in transition. I don't want to read about interposition or components or capabilities. I don't want to see your copy-pasta goals from WASM (which aren't clear for WASI). You're an API. Show me the API.

jedisct1 3y ago
https://wasix.org/docs https://wasix.org/docs may be what you are looking for. The WASI section documents WASI as it is implemented today. But since then, WASI pivoted and has become an umbrella for multiple projects. This is not just an API any more, and at the moment, the documentation on the WASI site and repositories is for WASI developers, not for developers using WASI. So if you didn't follow the whole thing, it is indeed be very hard to understand. The stack is complicated. But the ultimate goal of the project is to actually make it easier for developers to use wasm, without having to worry about all these details. It's essentially about adding dynamic linking to wasm. The dynamic libraries embed the function prototypes, so that calling functions with the wrong type will cause a link error. That requires the definitions of every type of function, and WIT, WAI and WITX are domain-specific languages to do that. Right now, WebAssembly is limited to static linking. It works very well, even across languages, but types aren't automatically checked. Actually, they are, but only using the primitive types available in WebAssembly. Here, the goal is to support something very close to the Rust type system. The proposal also allows restricting every library to their own memory region. So, a buggy or malicious library can only mess with its own data, not with the rest of the application.
- skybrian 3y ago
  Interesting. This seems almost like an object-oriented system where the objects can be large libraries written in different languages. Do libraries have a lifecycle? Can you instantiate multiple instances of them?
- SnowProblem 3y ago
  A million times better. Looks like this comes from the Wasmer team.
Philpax 3y ago
> Tell me what your project does in clear English. Okay. "Define a set of portable, modular, runtime-independent, and WebAssembly-native APIs which can be used by WebAssembly code to interact with the outside world. These APIs preserve the essential sandboxed nature of WebAssembly through a Capability-based API design." That's the first goal. > I don't care about wit/witx. I don't care the repo being in transition. I don't want to read about interposition or components or capabilities. Everything you've just mentioned is relevant to people implementing the spec, given its wide scope and nature. It is not reducible complexity. It is not a drop-in replacement for POSIX (i.e. it is not "a standard for 50 functions"); it goes beyond that, and aims to provide a secure and modular way to interact with the system where capabilities can be delegated or reduced.