Evaluate compatibility between WASI snapshot 1 and next

[codefromthecrypt]

Per WebAssembly/WASI#215 (comment) I found this is the new WASI API in progress

https://github.com/WebAssembly/wasi-filesystem/blob/main/wasi-filesystem.wit.md

Let's check to see if there are signature incompatibilities before we decide if and how to export a WASI go interface

[codefromthecrypt]

WebAssembly/WASI#469 (comment) also is interesting as the "rights" concept is being dumped. We should avoid implementing that, but this also hints the new WASI is a different API

[codefromthecrypt]

found this which hints the next will be named "wasi_snapshot_preview2" https://github.com/sunfishcode/wasi-wiki/wiki/Preview2-Plan

I perused the types and to best of my knowledge they aren't using anything fancy like i128 or externref @sunfishcode can you confirm?

[sunfishcode]

Yes, that proposal is using the component model's set of types which doesn't include 128-bit integer types, and the Canonical ABI, which doesn't use externref.

[codefromthecrypt]

thanks a lot for the clarification! @sunfishcode

[codefromthecrypt]

One major change is the decentralization of specs. For example, there's a subspec for clocks and no shared errno. However, as WASI doesn't require the component module, a monolithic module import as hinted earlier seems implied.

https://github.com/WebAssembly/wasi-clocks/blob/main/wasi-clocks.abi.md
https://github.com/WebAssembly/component-model/blob/main/design/high-level/FAQ.md#how-does-wasi-relate-to-the-component-model

@sunfishcode a couple more questions, just so we can know where to subscribe.

• do you know which repo or file inside it will track non-component use of new WASI (Ex a monolithic "wasi_snapshot_preview2" import)?
• do you know any implementation that has started work on any of the new WASI components?

[sunfishcode]

One major change is the decentralization of specs. For example, there's a subspec for clocks and no shared errno.

That's right. Avoiding a single shared errno makes it easier for APIs to offer more descriptive error values. I expect wasi-libc will convert various API's errors into a shared errno, for POSIX compatibility.

However, as WASI doesn't require the component module, a monolithic module import as hinted earlier seems implied.

https://github.com/WebAssembly/wasi-clocks/blob/main/wasi-clocks.abi.md https://github.com/WebAssembly/component-model/blob/main/design/high-level/FAQ.md#how-does-wasi-relate-to-the-component-model

@sunfishcode a couple more questions, just so we can know where to subscribe.

* do you know which repo or file inside it will track non-component use of new WASI (Ex a monolithic "wasi_snapshot_preview2" import)?

The component-model repo, which also covers the Canonical ABI, which is the basis for non-component versions of component interfaces. And the wit-bindgen repo, which is where the main implementation of the Canonical ABI is being developed.

* do you know any implementation that has started work on any of the new WASI components?

It's possible to implement wit interfaces using Wasmtime and wit-bindgen, and various people are doing this today. I plan to start work on Wasmtime implementations of the new wasi-filesystem and other new APIs soon.

[codefromthecrypt]

Thanks @sunfishcode I'll follow the component model repo for any updates on this, and thanks for the hints meanwhile!