Clarify which proposals are targeted to wasip1 vs component model wasip2+

[codefromthecrypt]

wasip1 is currently in use by a lot of compilers today. It is defined completely differently than wasip2+, as it is formalized as an ABI in witx and goes into the monolithic module name "wasi_snapshot_preview1" (vs component model which is a different approach altogether and not monolithic).

Currently, the proposals list doesn't clarify the target of things, so we can't tell if something is in witx by accident of not being converted to wit, yet, or if it is intentionally supposed to be added to preview1

https://github.com/WebAssembly/WASI/blob/main/Proposals.md

Can you please add a column for which proposals are active work on preview1 vs component model? This will prevent surprise and ambiguity. This also helps compilers and runtimes plan what sort of additions are likely, as it affects design.

Case in point: @yoshuawuyts corrected my misunderstanding that wasi-threads is actually a feature ready to be a rust triple, and that it is a part of preview1. I have seen so many wasi proposals converted from witx to wit (component-model), so it wasn't obvious to me.

The ecosystem should be able to know easily what work is ahead of them, especially what's backported to wasip1 and what despite being phase 1 is really just a clerical problem and ready for compilers to implement.

See rust-lang/rust#112922 (comment)
See WebAssembly/wasi-threads#47

[pchickey]

Yes, WASI Preview 1 was specified in terms of witx, which predated the component model and defined its own ABI. We defined the wasi_snapshot_preview1 module before WASI was specified as a set of proposals - the WASI spec itself was monolithic at the time.

Some WASI proposals (to my knowledge, this is only wasi-nn and wasi-crypto) have provided a witx interface in their repo so that they could be implemented as an extension to WASI Preview 1. Those proposals chose to use module namespaces of their own (e.g. wasi_ephemeral_nn, wasi_ephemeral_crypto_symmetric) for those extensions.

Proposals targeting Preview 2 need to be specified in the Component Model's wit language. When using recent additions to the wit language, proposals also get their own wit package name (e.g. wasi:io) to provide modularity similar to the module namespacing for the witx-specified proposals.

We hope that the proposals currently specified in witx will also propose wit interfaces when they are able to, but wit itself and all the component model tooling is still under constant development with occasional breaking changes at this time, so its understandable if proposals choose to wait for that progress to settle down. We we expect this churn will settle down soon, as we try to stabilize WASI proposals in order to release a Preview 2. (A plan for releasing Preview 2 will be proposed at the next WASI meeting WebAssembly/meetings#1322.)

wasi-threads has not sought a WASI subgroup vote to advance beyond phase 1 (which only grants the proposal a repository in which to build a proposal), and it is incorrect to call it "part of preview 1".

The wasi-threads proposal was never specified in witx, but @abrown et al landed implementations their proposal in wasmtime, wasi-libc, rust and elsewhere in terms of a core wasm ABI that resembled the wit document in their spec repo. (They did so because wit tooling was in an early prototype phase and wasn't stable enough to use at the time.) Simultaneously, the component model specification and implementation progressed so that it is clear that the wasi-threads proposal, in its current form, can't be faithfully represented as a wit interface: it requires engine integration that the Component Model cannot provide.

So, the existing implementations of wasi-threads are ad-hoc in terms of a core Wasm ABI, and won't compose with other proposals specified in wit. This is fine: we expect that implementations will drift from the spec repos as part of the maturation process, because these proposals can only mature by building implementations and discovering issues. Early phases, especially phase 1, is not a promise of stability - it only indicates that specification work is in progress, and provides a place to collaborate on it.

My understanding is that, presently, @abrown, @lukewagner and others are collaborating on how to take the core ideas from wasi-threads and turn it into a core WebAssembly proposal (built on top of the WebAssembly threads proposal, which itself is at Phase 3 in the Wasm subgroup), and they also will be figuring out how their proposal will interact with the Component Model proposal. So, we don't yet know the future of wasi-threads: it may end up getting eliminated by adding spawning and destroying threads to the core Wasm spec. Or, maybe the core spec work will require some other way of getting it specified and implemented. These things take time to shake out because there are a lot of implementors collaborating from many different Wasm engines.

[codefromthecrypt]

Thanks for the clarification.

FWIW I think the easiest way for engines would be to try to handle this at the core spec level, decoupled from GC but also integrated in case it exists. If opcode args aren't the way out to handle the state machine, allowing the core spec to define built-in functions is one consideration. These are just thoughts and I don't intend to debate, just since I opened the issue, wanted to give context for someone to consider or not (either way)

I'm closing this because you answered the question, and that was helpful.