Can and should WAMR be subsumed into WASI as a world?

[SamuraiCrow]

It appears that the WebAssembly Micro-Runtime isn't making much traction. Is it possible that it can be included into WASI as a world of interfaces? Secondly, would there be a practical reason to do so?

[linclark]

Can you explain a bit more what the hoped-for outcome would be?

I ask because when I see "WAMR", I think of this project, which is a runtime implementation, whereas WASI is a set of interfaces which runtimes like WAMR implement. When you say "WAMR" here, are you talking about the set of custom APIs that WAMR implements that are not part of any standard?

If so, then they could definitely share wit definitions for those interfaces and create a WAMR world that includes both their custom APIs and WASI APIs. It wouldn't even need to happen within WASI for them to do that. And if the WAMR folks want to standardize their APIs in WASI, they can also put forward proposals to do that. However, that is something that the WAMR folks would need to drive.

[SamuraiCrow]

Thanks! I was just about to add that link to my post for clarification! While WAMR isn't exactly what I was expecting to use, it does seem to encapsulate the basic outcome of what I was hoping WASI will provide in the end.

Being able to wrap a GUI based interface in such a way that it could be abstracted into something that resembles Google's Flutter framework with the Dart Native language dependency removed. Another example is how wxWidgets allows C++ code to be written for Windows, Mac and Linux and wrap their native GUI libraries without adding much overhead, simply by taking advantage of the static linkage exception in their GPL-based license. There are other frameworks as well. If there were some way that the common portions could be agreed upon without amounting to a runtime outside the native OS interfaces, that would be ideal.

I guess a better question would be: "Where would be the best place to start standardizing such frameworks?" Java tried to make an abstract windowing toolkit (AWT) that was pretty useful, but then they made Swing instead which layered a whole additional GUI library on top of the native windowing and looked like a foreign country had been set up within the screen real-estate of the original OS. That was the start of what went wrong with Java. It tried to be a world unto itself and continues to harass Google for using a custom runtime with the properly licensed Java compiler on Android. There's a lot that can go wrong with quasi-standards created by individual companies.