8 ms·

I've never seen a worse-described project than WASI. "Component model interfaces always support link-time interposition." Like WTF does this mean? The repo te

I've never seen a worse-described project than WASI. "Component model interfaces always support link-time interposition." Like WTF does this mean? The repo tells me nothing and I've still yet to see a clear write-up about what WASI is. I click on "docs" folder and there's one file. https://github.com/WebAssembly/WASI/blob/main/docs/WitInWasi.md https://github.com/WebAssembly/WASI/blob/main/docs/WitInWasi.... WTF is wit? This should be in a CONTRIBUTORS.md not in the docs folder. I click on "legacy" and I see preview0 and preview1, which are basically unreadable proto-specs. Wikipedia tells me WASI is a POSIX-like interface but with POSIX I know exactly where to look up the functions. Where's a single well-written WASI spec? I'll be honest - this whole project feels like candy for architecture astronauts and goes against the spirit of WebAssembly. Looks at how well-written WebAssembly's goals are: https://webassembly.org/docs/high-level-goals/ https://webassembly.org/docs/high-level-goals/. Their spec is easy to find and easy to read. This is what I want from WASM. Whatever WASI is doing, I don't like it. And neither does AssemblyScript team apparently: https://www.assemblyscript.org/standards-objections.html https://www.assemblyscript.org/standards-objections.html.

pjmlp 3y ago
To put it bluntly, they are redoing SOM, CORBA, COM and .NET component model, and calling it a novelty.
- CyberDildonics 3y ago
  Yes I agree that this is novel and a new frontier in software.
skybrian 3y ago
They mean that an environment can always provide a fake version of a function to a webassembly program. They’re defining an API but there’s no requirement to implement it. It seems like a rather weak specification where nothing is required to work? But at least it defines an interface. You might compare it to Go or Java interface types.
- jedisct1 3y ago
  You're referring to yet another part of WASI, which is indeed about defining domain-specific sets of APIs. No specific set is required to be implemented. So an application can work somewhere, and not load elsewhere. But the idea is that similar environments will hopefully implement similar APIs, and there's a mechanism to encourage that ("worlds"). Not only interfaces are defined. As an illustration, the WASI Crypto proposal includes a lot of details on how individual functions must behave, because in this context, it's critical to avoid inconsistencies between implementations.
  - skybrian 3y ago
    Good to hear. I was basing what I wrote on the previous sentence: > This can be used to adapt or attenuate the functionality of a WASI API without changing the code using it. It sounds like someone (who?) can use middleware to override an API to do whatever they like, even though there are specifications elsewhere about what they must do. In the context of virtualization, would this allow things like running one virtual machine inside another? Sandboxes all the way down?
    - jedisct1 3y ago
      It's more like regular shared libraries. You can replace a library with a different one that loads the original library, defines the same symbols, and forwards the function calls. That's how debugging/protocol inspection tools like 6Jack work, and it's pretty convenient. It could be done with static libraries, but that would require renaming all the symbols of the upstream library.
Philpax 3y ago
> "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.
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
IshKebab 3y ago
It's basically a POSIX interface for WASM. I also agree with the AssemblyScript people. WASI is driven by people saying "I want to be able to compile existing Linux software to WASM and run it on a server!" and to do that they have pretty much just copied POSIX. Great for running old software, but it seems very short sighted to me to tie WebAssembly to 70s UNIX design. It'll probably be popular because people apparently love never fixing things...

pjmlp 3y ago

To put it bluntly, they are redoing SOM, CORBA, COM and .NET component model, and calling it a novelty.

CyberDildonics 3y ago
Yes I agree that this is novel and a new frontier in software.

skybrian 3y ago

They mean that an environment can always provide a fake version of a function to a webassembly program. They’re defining an API but there’s no requirement to implement it. It seems like a rather weak specification where nothing is required to work? But at least it defines an interface. You might compare it to Go or Java interface types.

jedisct1 3y ago
You're referring to yet another part of WASI, which is indeed about defining domain-specific sets of APIs. No specific set is required to be implemented. So an application can work somewhere, and not load elsewhere. But the idea is that similar environments will hopefully implement similar APIs, and there's a mechanism to encourage that ("worlds"). Not only interfaces are defined. As an illustration, the WASI Crypto proposal includes a lot of details on how individual functions must behave, because in this context, it's critical to avoid inconsistencies between implementations.
- skybrian 3y ago
  Good to hear. I was basing what I wrote on the previous sentence: > This can be used to adapt or attenuate the functionality of a WASI API without changing the code using it. It sounds like someone (who?) can use middleware to override an API to do whatever they like, even though there are specifications elsewhere about what they must do. In the context of virtualization, would this allow things like running one virtual machine inside another? Sandboxes all the way down?
  - jedisct1 3y ago
    It's more like regular shared libraries. You can replace a library with a different one that loads the original library, defines the same symbols, and forwards the function calls. That's how debugging/protocol inspection tools like 6Jack work, and it's pretty convenient. It could be done with static libraries, but that would require renaming all the symbols of the upstream library.

Philpax 3y ago

> "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.

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

IshKebab 3y ago

It's basically a POSIX interface for WASM. I also agree with the AssemblyScript people. WASI is driven by people saying "I want to be able to compile existing Linux software to WASM and run it on a server!" and to do that they have pretty much just copied POSIX. Great for running old software, but it seems very short sighted to me to tie WebAssembly to 70s UNIX design. It'll probably be popular because people apparently love never fixing things...