This is a very well stated and accurate depiction of how wasm has evolved over the years & I couldn’t agree more with your recommendation.
WASI 0.1 should really be improved however necessary to increase secure POSIX compatibility— I think it’s already good enough, and implemented widely, but would be happy to see more APIs in it as long as it doesn’t sacrifice the security of many use cases of wasm.
I agree that WASI 0.2 is too far of a leap from this, creating an entirely new conceptual system in top of wasm, that is not compatible with the standard at all, and will damage the overall wasm ecosystem by fracture.
WASI 0.2 and Component Model are Bytecode Alliance projects and should be collocate in their own GitHub org. Associating them in the WebAssembly org is irresponsible and conveys a false alignment with the overall community and reality of Wasm standards.
I'm sorry I think this is just so sad & lowly. A portability layer for old code seems like such a lowly sad objective, such an incredibly sad unambitious target. I get the want, but letting such a small world dominate would be horrific. It's pathetically unambitious & small.
Wasm has not allowed actual inter-language operation at any serious scale. When we use code, it's basically bundled in, and maybe maybe maybe rust can pull in some c code because of it's own ffi, but that's as much as you get. That will never ever lead to wasm being a broad ecosystem. Everything will be its own distinct thing forever, and that's not a web assembly module if it so drastically fails to get anywhere near any modularity asks.
These small minded asks & desires should not outshadow real ambition. For a practical view of what we should be hoping for, the famous Steve Sanderson has a demonof three-way language interop using wasi preview2 that would not in any way be remotely conceivable in preview1. Spare us from the retrogressives that argue the shallow short preview1 would be anywhere near enough of a stopping point; that would be absurd. https://youtu.be/p9taQkF24Fs
No one is saying anyone should stop exploring new paths. I don't know what you personally are bringing to the table as far as adding to the ambition, so excuse my naivety.
The issue is that there is a misrepresentation by the Bytecode Alliance about WASI, from where it began, to where it is now. And a lot of this has been poorly communicated or not done at all. Which has only left many of us to think that they are trying to pull a fast one over the community to forcefully bring everyone along into Components when that is not desirable.
> Wasm has not allowed actual inter-language operation at any serious scale.
This is untrue, and you may just be unaware of efforts like Extism [0]. While it is intentionally not a binding generator, it does make it very easy to blend languages meaningfully. Disclaimer, I work on Extism and therefore have some bias :) We have different goals than the Component Model, so if you actually want what the component model offers, you should use it!
I believe the easy solution here is to:
1. stop referring to WASI 0.1 as "legacy", implying some obsolete status, or call 0.1 something entirely different. Let it continue to be an easily targetable interface to bridge to the rest of today's software.
2. move WASI and Component Model code repositories out of the WebAssembly github org.
This would clarify the distinction between WebAssembly (the standard) and WASI 0.2 / WIT / CM as a project by Bytecode Alliance. They are not the same, and while the Bytecode Alliance works on making things usable and ready, it doesn't cause harm or confusion for WebAssembly users.
WASI 0.1 should really be improved however necessary to increase secure POSIX compatibility— I think it’s already good enough, and implemented widely, but would be happy to see more APIs in it as long as it doesn’t sacrifice the security of many use cases of wasm.
I agree that WASI 0.2 is too far of a leap from this, creating an entirely new conceptual system in top of wasm, that is not compatible with the standard at all, and will damage the overall wasm ecosystem by fracture.
WASI 0.2 and Component Model are Bytecode Alliance projects and should be collocate in their own GitHub org. Associating them in the WebAssembly org is irresponsible and conveys a false alignment with the overall community and reality of Wasm standards.