3 ms·

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 im

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.

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.