Adding document for comment

[woodsmc]

Added the document in its current state for comment as an open PR.

[abrown]

Abandoning these early adopters without a viable migration path...

This is not a fair judgment of how toolchains like wasi-sdk and wasi-libc have approached the requests for longer support of p1 — I would say this language is a mis-characterization and should be fixed. I have had many conversations with @woodsmc, @loganek, etc. in which they expressed a desire for long-term support for p1 in those toolchains. And, in fact, here's one of my efforts to support that desire from exactly one year ago: WebAssembly/wasi-libc#476.

But note the lack of feedback from the "keep p1 alive" parties in that PR: I believe that it is the responsibility of those who want to maintain p1 stability to be invested in that work, not leave it to others. Those who are moving the specification forward (p2, p3, etc.) should not be forced to have the same stability motivation as the "keep p1 alive" parties. And that is an open invitation for the "keep p1 alive" parties to increase their support for the parts they care about; I feel both goals, progress and stability, are still clearly possible at this point.

[rajsite]

Maybe it's an oversimplification / mischaracterization but I believe the largest concerns with preserving p1 interfaces is more about preserving core wasm module format and interfaces. I'm optimistic that WebAssembly/component-model#378 will provide the alternative that the "keep p1 alive" parties would want without the current limitations of what is in the scope of p1 / extending the interfaces in p1.

[abrown]

@rajsite, yeah, I agree with your "largest concerns" assessment. And I guess that strengthens my point: it is not as if toolchain maintainers have "abandoned" p1, but rather that the companies represented by this document should invest in making the issue you link to (and/or my draft PR) a reality.

[woodsmc]

Hey @abrown, thanks for considered thoughtful feedback, it really is much appreciated. In large what I hear you saying actually aligns with the document. You are highlighting the need for those organizations who require the 0.1 toolchain to get involved with it, as the those taking the standard forward don’t see a need to do so.

There is no judgement in the document. But the document does need to very clearly and very transparently describe the state of current support for the WASI 0.1 toolchain, along with the wider implications of this.

There are organizations I have met who believe that WASI 0.1 is going to have indefinite support. They believe that this support will be provided for by those moving the standard forward. This is not my understanding. Reading your comment you seem to suggest the same thing. The mistaken believe that there will be indefinite support has resulted in a lack of attention on WASI 0.1 stability – something the document is trying to address.

Are there any published plans for WASI 0.1 support, that the document authors may have missed? – If so then yes then we should accurately reflect these in the document.

My honest, personal understanding is that this does not exist. My understanding is driven by my personal conversations with you, other members of the BCA TSC and folks in Fastly and Cosmonic. When I enquired about longer term support the response I received was the same from every party, that WASI 0.1 was a preview and should not be used. As I explained on the E-SIG call, and included in the overview of the document, that boat has sailed. We (those people using WASI 0.1) need to provide this missing longer term support.

As we move forward to provide this support and start defining the concrete next steps there may be initiatives that we’ve not been involved in which we should. The PR you linked to is a great example of that, and I’m grateful you pointed that out.

Regarding the next steps, I am much more interested in yours and others’ opinions on how the renewed investment in WASI 0.1 can be managed alongside the evolving 0.2+ releases. The document authors spent a considerable amount of time trying to work out a compromise that could work for all.

I can see the WASI 0.1 / Embedded folks wanting to move forward with some new additions to WASI 0.1 to provide missing system level functionality. I can envision this happening within the next month or so.

[woodsmc]

@rajsite, yeah, I agree with your "largest concerns" assessment. And I guess that strengthens my point: it is not as if toolchain maintainers have "abandoned" p1, but rather that the companies represented by this document should invest in making the issue you link to (and/or my draft PR) a reality.

This appears to be a call to action. I love this, and I really appreciate you calling out the need for investment. It is something we should consider in the E-SIG as we define the concrete next steps.

[abrown]

In large what I hear you saying actually aligns with the document [...] But the document does need to very clearly and very transparently describe the state of current support for the WASI 0.1 toolchain, along with the wider implications of this.

I do understand many of the underlying concerns but what I'm pointing out is that what the document is describing, whether clearly or transparently, is actually incorrect: IMHO, p1 users have not been abandoned by toolchains and there is a viable migration path (see the links above).

[ttrenner]

From what I've seen it'd be correct to state that there are existing approaches to support migration in terms of the generation of wasm modules (by wasi-sdk) (based on your sketched approach) and proposals that could help to make p2-modules workable on p1-runtimes (see Marcin's proposal).

Other than that, the document tries to state that there are gaps in current p2 tooling that reflect p1 functionalities and non-functional requirements of the embedded domain. That does not mean, that there are no ideas of how to do that based on p2. It just means, that it does not exist yet. Plus, there are concerns that - in case that there will be no means/support for low-level api support - P2 might not do the trick for the needs of the embedded domain. This concern might be wrong, but it is reality, that p1-based products are already running on tons of "embedded" devices. So, p1 is "proven in use" and hence the risk of extending and improving p1 seems to be lower than hoping that P2+ will work for the embedded domain in future.
The concerns about P2+ could somehow be tackled if there is an agreement to place quality gates in the phases. Note, that this is also brought up in the document. I have not seen any comment on that, which makes me feel like that there is little to none support for that. Again, bear with me if I am wrong with that - maybe there was no opportunity to dig into this.

The document also tries to sketch an solution to let both concepts (P1-like and P2+) work: a layered approach. The bottom layer is just about supporting low-level APIs, while the top layer does all the nice things to get interlanguage interoperability (component model) - by the way: having a well-defined way for FFI declaration is wanted by the embedded domain but not for the price of performance, when performance is more important and Posix, using C ABI etc., does the trick (also accepting the trade-off of being forced to accept another way for FFI declaration or the trade-off of not having the possibility to mix languages).
Now, there are comments that the layering approach might not be necessary, because it might be doable with P2+ approaches. This seems to be a bet in the future, at least as long as there are no working examples showcasing this broadly. I admit that there are examples when looking at shared memory. Stream of P2+ seems to serve well for a couple of use cases. But there are use cases where stream does not seem to be the best solution (e.g. in case random access is needed and well-known MMU features (using mmap) are enough for a specific use case). Plus, there are different approaches out there, e.g. WAMR's shared heap (which also does not fit for all the uses cases that need "shared memory": e.g. if sharing is needed across different processes (albeit with all the cons that come with it!)).

There is legacy software, that is based on Posix. There is legacy software, that should be ported easily to the wasm world, i.e. clone the repo and issue clang/cmake and generate a wasm module. There are missing gaps like signaling (which has been discussed here back in the days). In the linked issue it is highlighted, that signal handling is not an easy task and maybe not everything is needed (and not all of it might be sensible in the "Wasm realm"). Also, maybe, not everything of Posix is needed. But we do not know yet. But we know that there are examples that need to set thread-attributes or socket options (e.g. unblocking source). Such software needs more "posix like" support and it feels to become overcomplicated (incl. performane loss) to map (and re-do?) it to p2+ approaches if it is not needed for a given use case.

Long story short: Anticipating all the different use cases does not seem to be realistic and hence we are advocating for a more flexible approach of interacting with the "underlying system" - I think that the layered approach is worth to be discussed. I'd be irritated if this is not even considered worth to talking about.

[edit] changed some wording and typos - sorry for the inconvenience.

[woodsmc]

In large what I hear you saying actually aligns with the document [...] But the document does need to very clearly and very transparently describe the state of current support for the WASI 0.1 toolchain, along with the wider implications of this.

I do understand many of the underlying concerns but what I'm pointing out is that what the document is describing, whether clearly or transparently, is actually incorrect: IMHO, p1 users have not been abandoned by toolchains and there is a viable migration path (see the links above).

@abrown - There has been a tremendous amount of engineering and effort expended to keep the WASI 0.1 tool chain functioning as it is today. You are right we should call this out in the document. It is something I know all users of WASI are very grateful for.

The document is doing a little bit of a hamfisted job of it, but it attempts to point out that there is such a resounding lack of commitment from anyone, either the users of 0.1 or the contributors to moving the specification forward to maintain that support. We know that there are commitments to continue work on WASI 1.0+, but nothing exists for 0.1, this lack of support (it doesn't appear deliberate, more like it's fallen between the gaps) is effectively the same as abandoning the 0.1 users. This is particularly true when you combine it with the lack of WASI 0.1 runtimes to execute code targeted at WASI 0.2,0.31.0RC and beyond. The result is a tool chain that's no longer supported and a runtime that can't execute the latest binaries...

In drawing attention to this, the intent in the document, is to demonstrate the need to step up and contribute.

I'd appreciate some help with the wordsmithing to get this all in the document.

[abrown]

@woodsmc, thanks for moving this to a separate PR — it's a lot easier to review. Have you already dealt with the issues brought up in #10 or were you planning to get to that at some point? (I just didn't want that valuable feedback lost in the move!).

[woodsmc]

Thanks for reminding me!- That is very much appreciated. For completeness I've copied @lukewagner's original issue text from here and I've inlined my responses from that thread. The two edits suggested in my responses have been applied ( I know these got a little lost in the transfer to the PR, I appreciate everyone's patience with this). To help the reader, my original responses from the original issue are prefaced with "As noted:".

Unfortunately #9 was not kept open to allow feedback; perhaps we could do that in the future since it makes it easier to have threaded discussions.

As noted: Good call. Wasn't intentional and good feedback.

In any case, there are some pretty significant inaccuracies in the Introduction, Problem Definition and Status Quo sections, which I'll quote and describe:

An initial release candidate for WASI 1.0 is expected to be released by the end of the year. However, based on current implementations and the publicly shared roadmap, WASI 1.0 will be largely unsuitable for embedded applications.

I don't know where this comes from, but it's quite untrue. The timeline presented at the last two CG meetings indicates a 1.0 "release candidate" no earlier than mid-2026. And then further work is required to (1) split off a separate W3C Working Group for WASI, (2) advance stages from "release candidate" to actual standard 1.0.

As noted: Yup, let's update the document to reflect that. This now reads:

As of early 2025, the WASI 0.2 release is available, with 0.3 expected in the coming months. An initial release candidate for WASI 1.0 is expected to be released by no later than mid-2026, at which point there is a desire to seperate the standardization process by the creation of a new W3C charter - [link with details]([Wasm CG Feburary 2025 - Google Slides](https://docs.google.com/presentation/d/1z0WXS5BLFtbVynM9xAyilecYskN1IKe9Dad1nDEmgU8/edit#slide=id.g33067d21cc1_0_321)).

Thus, it's far too early to speculate on whether or not WASI 1.0 will be suitable for embedded applications and so I think this paragraph should simply be removed.

A significant challenge is the lack of a viable migration path for existing WASI Preview 1 runtimes. [...]

There are several migration paths being discussed at this moment with folks in this SIG. One of the most promising, whose viability is already demonstrated by jco, involves preprocessing component binaries into core modules that can be run with modest additional effort by existing core wasm runtimes. Extending this approach to more core runtimes like WAMR seems quite viable, and so the quoted sentence and much of the following paragraph seems incorrect. I think it would be more appropriate to explain the current challenge and say that solutions exist that would require far less engineering effort than implementing the Component Model from scratch.

As noted: To be 100% transparent with everyone we should state the difference between feasible, viable and concrete reality. Jco show's a feasible way of addressing this. It may not be viable due to binary image size, implications on potential changes to runtimes (which won't work for ROM based RTs which cannot be updated), performance and memory footprint. From a concrete reality perspective, there isn't a single partner who has committed to build the necessary Jco like infrastructure for the embedded ecosystem.

We should be really very clear with everyone about this. In this regard, there is no solution yet. It is important that we call out this gap. When WASI RC 1.0 is released in 2026 what support will P1 runtimes have? Pretty much none - This is critical to know for everyone, particularly in the embedded folks, as it has a direct impact on business continuity.

Another critical gap is the absence of low-level, system-oriented APIs that are both efficient and predictable. [...]

There are indeed low-level system-oriented APIs that are actively being implemented and proposed in WASI and the Component Model. While it's true that there is more work to be done to reach the optimal goal state, there's more work to extend WASI Preview 1 as well, and the primary challenge here isn't specific to the Component Model at all; as #7 illustrates, the key tensions are inherent to WebAssembly and concern designing efficient, portable, secure APIs that run across the embedded target matrix this SIG has produced. Instead, I think we should list the concrete use cases which are currently sub-optimal, under which we can list the solutions being proposed for implementation.

**As noted: ** It's really important to be clear with the reader - these interfaces are currently not present. In this regard the document paints an accurate picture, they don't exist.

I do understand that there are steps to address this and a desire to do so, which is awesome. While there is a lot of good will to try to overcome these issues, I don't recall seeing any contributor promise to provide this, nor do we have a standards process that would mandate it.

So we have to be transparent - right now it doesn't exist. It may not exist in WASI 1.0 RC in 2026.

Finally, there is no straightforward way for core WebAssembly modules to interact with Component Model-based binaries. [...]

There are a number of ways this can work. One browser-oriented solution is arrived at at the end of component-model/#275 which could work analogously outside-the-browser. Stating "there is no straightforward way" is thus not true; a more accurate statement would be that it is not implemented yet.

As noted: Good point. Let's update that to "no currently available way" (done). This now reads:

Finally, there is no currently available way for core WebAssembly modules to interact with Component Model-based binaries.

As a higher-level abstraction, the Component Model introduces inefficiencies and limitations that make it unsuitable for many low-level use cases.

I don't think this is true as a general statement. The Component Model already avoids many forms of overhead through its low-level Canonical ABI, and most of the remaining known problems are in the process of being fixed. Instead, I think we should list the cases where the Component Model's Canonical ABI is currently sub-optimial, and we can then list the particular changes/additions being discussed that would fix these. As is, the document ignores all the hard work and discussion across this SIG that has been done specifically to address these concerns, such as CM/#383, CM/#175 and, most recently, discussion around whether we could standardize WAMR's shared heaps feature. Leaving out these developments significantly skews the overall picture.

Problem Definition
[...]
Key challenges include:

Items 2 and 3 should be reworded to reflect the comments above.

WASI 0.2 (previously known as “Preview 2”) – Announced three years ago and officially released one year ago

WASI 0.2 was released one year ago; I don't know where "announced three years ago" comes from. The implication seems to be that 0.2 was mostly-done for three years, which is quite untrue; 0.2 only finished implementation a few months before it was released.

As noted: There is no implication intended. Only the desire to state the date of the announcement, as this clearly impacts adoption of Wasm / WASI, the traditional case study for this is The Osborn Effect.

100% let's correct the date. If you've a more accurate date for the announcement, we can change this.

WASI 0.3 – Currently in development, this version is expected to be released within the next six months, further iterating on the Component Model-based approach. It introduces enhancements to asynchronous operations, including the addition of future and stream types

As relevant to this document, we should extend the end of the second sentence with "and a low-level memory-sharing ABI for efficient bulk transfer of data into and out of WebAssembly linear memory".

As noted: Could you be a bit more specific? - Are you talking about caller supplied buffers? Or streams (since the sentence states streams already?) - Regarding efficiency, do you have a data point you'd like to share? - I know a lot of the document discusses efficiency, so a data point here would be wonderful, particularly one that contrasts the same operation with native, 0.1, and the 0.3 version. It would be epic!

With WASI 1.0 expected to finalize this transition, existing WASI Preview 1-based runtimes and applications face an uncertain path forward. The lack of clear migration options risks fragmenting the ecosystem and leaving many early adopters behind.

This should be updated according to the above comment to mention the options available to us to allow existing core runtimes to support WASI and the Component Model with minimal additional effort.

[ospencer]

@woodsmc One thing that would help tremendously—could you separate out all things that are changes to implementations versus things that are changes to specifications? As a part of the BA and the E-SIG we're largely focused on things we can implement based on existing specifications. It's fine to have a list of things that would be nice to change in the WASI spec, but those discussions largely need to happen as a part of the Wasm Community Group—that should be a separate document that's presented to the CG. As a bonus, this will give this document a lot more focus, and we can work towards solutions with existing specifications.

[srberard]

While this document is not perfect, I'd like to see us merge this and start work on refining/updating it as a group. The fact of the matter is that today, we do not have a good solution for supporting existing code. As @ttrenner points out, it should be easy to take existing code and retarget it to WASI. WASI P1 is a big step in that direction but, as pointed out here, there are gaps. I'd like to see us pragmatically address these while, at the same time, not impede existing efforts around the Component Model.

I'll start by saying that I'm a fan of the WASI Component Model. I believe it offers a lot of advantages for application development as it introduces a modular approach bringing benefits like composability and language interoperability. However, systems and embedded programming generally have different priorities. These workloads emphasize efficiency, direct host interaction, and minimal abstraction, as they often run in resource-constrained environments where performance and simplicity are critical. While the Component Model provides useful capabilities for many use cases, its additional complexity is not necessary for low-level systems and embedded programming, where a direct and highly predictable execution model is required.

A concern, which has been expressed several times, is the overhead the Component Model introduces. While there has been several proposals and discussions about potential optimizations, concrete solutions have yet to fully emerge. I appreciate the willingness to address these and engage on such topics. However, in resource-constrained environments, added layers can negatively impact performance and increase complexity without clear benefits. In contrast, a direct syscall interface—like the one WASI P1 provides—is a well-established, efficient model that aligns with the needs of low-level software. I'm not saying that the CM won't get there, rather that it's not clear today and my bias is towards a simpler approach for these types of applications.

I agree with the proposed layered approach to WASI. This is a common design pattern for platforms such as WASI. Rather than suggesting a fork, I see this as an opportunity to have a structured approach to WASI, ensuring that development progresses concurrently while saying aligned. For example, I see opportunities for low-level APIs to support and provide the foundation for the higher-level CM model interfaces.

[woodsmc]

@woodsmc One thing that would help tremendously—could you separate out all things that are changes to implementations versus things that are changes to specifications? As a part of the BA and the E-SIG we're largely focused on things we can implement based on existing specifications. It's fine to have a list of things that would be nice to change in the WASI spec, but those discussions largely need to happen as a part of the Wasm Community Group—that should be a separate document that's presented to the CG. As a bonus, this will give this document a lot more focus, and we can work towards solutions with existing specifications.

Hi @ospencer, thanks for the feedback and suggestion. I think others have noted this in comments and in the document. The specification constrains the implementation space, this then dictates the performance of any implementation. You are correct that the specification changes should be discussed at a standards group. I think the right venue for most of this is probably the WASI SG, not the Wasm CG.

Interestingly, the document not only includes features / specifications, but also touches on changes to the standardization process itself.

Looking back at our charter, this document mainly address area 3 of the charter, and in part also areas 2 and 4. The logical next step, once this working document is merged, is to work on two presentations / technical notes to the SG as derivates of this document. These would be:

• Area 3 : Support for maintaining the existing tooling for WASI Preview 1
  Here we can provide the general use case, along with the set of features we would need to see added to the WASI 0.1 release.
• Area 4 : Forward Compatibility / Roadmap for future Convergence
  Here we can provide the proposed standards process mechanism for contributing to 0.1 while not slowing work on 0.2+. We can propose the phase gate quality changes (NFR checks) to the phased approval process which would help the CM naturally move to a state which is more amenable to use in the embedded world.

I expect these will be more concise. How about we add two new issues to track these two technical notes?

Edit: Issues here:

• Technical Note E-SIG -> SG : Area 3 Support for maintaining the existing tooling for WASI Preview 1 #19
• Technical Note: Area 4 : Forward Compatibility / Roadmap for future Convergence #20

[woodsmc]

Hey Folks... since this is an E-SIG that will not be presented to the SG in it's current form, following @ospeencer's suggestion, I'd like to set myself, and the document authors a challenge. Let's look to gather all feedback by Monday March 3rd close of business, US Pacific time. Then look to make sure that the document authors have addressed all the feedback by, say Thursday March 6th close of business pacific time. With a view to getting the document merged by end of the week next week.

Bit of a forcing function, but just so we don't spend too long on it, and move on to some of the constructive and exciting work we have in front of us.

Thoughts? Too short?