Inaccuracies in Alternative_Solutions_(WASI_Wasm).md

[lukewagner]

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

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.

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

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

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.

[woodsmc]

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.

Good call. Wasn't intentional and good feedback.

[woodsmc]

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.

Yup, let's update the document to reflect that.

[woodsmc]

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.

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.

[woodsmc]

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.

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.

(Edit: Spelling)

[woodsmc]

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.

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.

[woodsmc]

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 WebAssembly/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.

Good point. Let's update that to "no currently available way"

[woodsmc]

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

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!

[woodsmc]

Hi @lukewagner - thank you for the wonderful feedback and the time to put that all together. I can see a huge amount of good will here. I am personally very grateful for the input. While I'm not the only contributor to the document, as the guy who posted it, I've tried my best to respond ahead of the talk tomorrow, I apologize if I missed something, or miss understood anything. I'd encourage others to checkout your feedback too.

I am very much looking forward to the discussions.

The start of the document attempts to layout a basic gap analysis between what we have in 0.2 and 0.3 and what the embedded folks feel is required. In this regard it is important to be clear about what is implemented today and what isn't. I'm personally unclear on the gatekeeping process is as we work toward WASI 1.0 RC? - which makes it hard to say that a potential solution will ultimately result in a real solution at WASI 1.0 RC. - The old adage - "A bird in the hand is worth two in the bush" comes to mind.

I think it's important to be transparent with the reader, since it is only when we can clearly see what the gap is, that we can discuss what we need to do to cover it.

[yoshuawuyts]

On a procedural note: this thread is incredibly hard to follow. Given the number of factual inaccuracies found so far, this seems like it would benefit from a more thorough review by other BA members. But that's difficult to do on an already-merged document.

As such I'd like to propose reverting #11 and #9, and re-filing it as a PR so that others in the BA can review it and discussion can actually happen in a threaded manner. Issues really don't work well for reviewing draft documents, and if we can instead do that using GitHub's intended review workflow that would work significantly better.

[squillace]

This was a surprising read for me. I keep thinking: if we make the target systems (https://github.com/bytecodealliance/sig-embedded/blob/main/Target_Platforms/Embedded-SIG-Target-Platforms.md#5-publicly-available-hardware-platforms) work for testing and benchmarking and they meet the SIG's criteria, what remains of this document? We wrote that target platforms specifically so we could shoot for making them work. Am I mistaken?

[lukewagner]

Thanks so much @woodsmc for the initial responses. I think @yoshuawuyts is right that it's already quite difficult to follow this issue (and will be 10x more so after a few more rounds), so if we're willing to perhaps post a new PR, that might be nicer and I'll hold off until then.

[woodsmc]

As per our E-SIG discussion I've provided a framing / overview. This has bee submitted as a PR. You can find this here: #14

[woodsmc]

On a procedural note: this thread is incredibly hard to follow. Given the number of factual inaccuracies found so far, this seems like it would benefit from a more thorough review by other BA members. But that's difficult to do on an already-merged document.

As such I'd like to propose reverting #11 and #9, and re-filing it as a PR so that others in the BA can review it and discussion can actually happen in a threaded manner. Issues really don't work well for reviewing draft documents, and if we can instead do that using GitHub's intended review workflow that would work significantly better.

Github is awesome for code, but terrible for documents. As I recall, I think we ran into the same issue with the original E-SIG charter.

Switch to Google Docs?
We've the same document as a Google Document, which we could jump to. It's so much better for editing and review, and was how we originally authored the content. I'd be happy to share this, if it would make sense? -- I only posted it Github as it seems de rigueur.

It's much more important that we get to chat about the issues at hand, and not get mixed up with the tooling.

I don't think there are that many inaccuracies. I think the overview calls that out, that we're detailing what is available today and comparing that to what we need. As we are really seeking business continuity we can't state what might be, just what we have today. That's not to say there are not promising solutions, but is necessary to say that they are not available at the moment. ( think I did a better job of saying that in the call, and in the overview in the PR).

If you'd prefer to jump to the Google Doc, let me know, we can close this issue with a note to continue the conversation over on G-Docs.

[woodsmc]

For those interested the YouTube recording of the discussion around this document can be found here: https://youtu.be/-azsz9qv7qg

[abrown]

@woodsmc, I think @yoshuawuyts proposed a good solution for this: revert and re-open as a PR containing the whole document. Can you do that? I tried to make some comments about toolchains to #14 but that is just a change to the initial paragraphs so it is quite hard to make comments on the section I would like to, which happens to be unchanged.