Wasmtime GitHub notifications bot (Jun 28 2023 at 02:32): Wasmtime GitHub notifications bot (Jun 28 2023 at 02:32):trusktr opened issue #6656:
I wasn't sure where to post this, as I didn't see some sort of public forum for Bytecode Alliance, so posting here for now.
This project is interesting:
However it is currently focused only on bringing web APIs to JavaScript engines outside of browsers, and WebAssembly is not part of the picture yet.
I wonder if there's some sort of potential to get WebAssembly into the picture, so that APIs like the File System API can be standardized in a way such that it is usable in both JS engines and Wasm engines.
This would be an alternative to WASI. It would be different, and perhaps not useful for compiling existing and legacy C/C++ apps to WebAssembly, but useful in defining a new generation of applications built on common standards that don't leave the "web" in WebAssembly out of the picture for the new breed of apps that can build on these specs.
Wasmtime GitHub notifications bot (Jun 28 2023 at 02:32):trusktr edited issue #6656:
I wasn't sure where to post this, as I didn't see some sort of public forum for Bytecode Alliance, so posting here for now.
This project is interesting:
However it is currently focused only on bringing web APIs to JavaScript engines outside of browsers, and WebAssembly is not part of the picture yet.
I wonder if there's some sort of potential to get WebAssembly into the picture, so that APIs like the File System API can be standardized in a way such that it is usable in both JS engines and Wasm engines.
This would be an alternative to WASI. It would be different, and perhaps not useful for compiling existing and legacy C/C++ apps to WebAssembly, but useful in defining a new generation of applications built on common standards that don't leave the "web" in WebAssembly out of the picture for the new breed of apps that can build on these specs.
Wasmtime GitHub notifications bot (Jun 29 2023 at 10:30):philpax commented on issue #6656:
Hi! No opinion on the issue itself, but regarding the public forum for the Bytecode Alliance - check out their Zulip: https://bytecodealliance.zulipchat.com
You might be able to get more feedback there :)
Wasmtime GitHub notifications bot (Jul 05 2023 at 20:30):linclark commented on issue #6656:
@trusktr I think there can sometimes a tendency to see conflict where there isn't one.
We do currently have people active in both the component model work and the Winter CG. The Winter CG is not an alternative to WASI (and WASI is not monolithic; there are multiple different APIs that are being standardized by WASI). I can't speak for the Bytecode Alliance as a whole, but at Fastly we plan to support APIs from both. The one way in which WASI is special is that it forms a target on top of which other APIs can be virtualized, because it includes representations of platform primitives. This means you can have WinterCG-on-top-of-WASI (if that's what you want).
From the Wasmtime perspective, whether an API is Winter CG or WASI doesn't matter. Embedders can choose to provide whatever APIs they want. They can also choose not to include whichever APIs they don't want... it's completely up to what you want to do!
The underlying machinery for exposing the APIs is the same: the Winter CG APIs would be represented using .wit file and various collections of APIs could be brought together in wit worlds. And it would also be possible to define a world that exposes both Winter CG APIs and WASI APIs.
It's this underlying machinery for exposing these APIs that Wasmtime itself is concerned with. Given that the underlying machinery is the same no matter what, any further conversation about the pros and cons of different proposed APIs should probably move somewhere else.
Wasmtime GitHub notifications bot (Jul 05 2023 at 21:42):jameysharp commented on issue #6656:
Thanks for that thoughtful explanation, @linclark! I'm going to go ahead and close this particular issue as out of scope for Wasmtime.
Wasmtime GitHub notifications bot (Jul 05 2023 at 21:42):jameysharp closed issue #6656:
I wasn't sure where to post this, as I didn't see some sort of public forum for Bytecode Alliance, so posting here for now.
This project is interesting:
However it is currently focused only on bringing web APIs to JavaScript engines outside of browsers, and WebAssembly is not part of the picture yet.
I wonder if there's some sort of potential to get WebAssembly into the picture, so that APIs like the File System API can be standardized in a way such that it is usable in both JS engines and Wasm engines.
This would be an alternative to WASI. It would be different, and perhaps not useful for compiling existing and legacy C/C++ apps to WebAssembly, but useful in defining a new generation of applications built on common standards that don't leave the "web" in WebAssembly out of the picture for the new breed of apps that can build on these specs.
Wasmtime GitHub notifications bot (Jul 09 2023 at 04:48):trusktr commented on issue #6656:
I suppose a more important question is, would it be good too officially support the spec, regardless of how it is implemented? (if it is on top of WASI, but people are directly using Winter, it still seems like an alternative).
Leaving it to library land won't be ideal, won't really make it a standard (I think it could be a good standard!) but would be a way to test it out.
Wasmtime GitHub notifications bot (Jul 09 2023 at 04:48):trusktr edited a comment on issue #6656:
I suppose a more important question is, would it be good too officially support the spec, regardless of how it is implemented? (if it is on top of WASI, but people are directly using Winter, it can still be considered an alternative).
Leaving it to library land won't be ideal, won't really make it a standard (I think it could be a good standard!) but would be a way to test it out.
Last updated: Dec 23 2024 at 12:05 UTC