Stream: git-wasmtime

Topic: wasmtime / Issue #2015 Add Additional Modules

Wasmtime GitHub notifications bot (Jul 14 2020 at 04:32):

AldaronLau opened Issue #2015:

In the readme, it says "Initially, the focus is on WASI Core, an API module that covers files, networking, and a few other things. Additional modules are expected to be added in the future."

I'm curious as to what it would take to start adding additional modules (I'm interested in contributing, and possibly helping design APIs outside of file management and networking).

Feature

Adding an API modules to cover something like a canvas (using JavaScript terminology), audio support, etc.

Benefit

Opens up possibilities to make graphics applications on WASI, or make a WASI virtual machine operating system (both are things I'm interested in doing).

Implementation

I think fairly minimal and simple asynchronous APIs inspired from cala::speaker/cala::microphone and cala::pixels/cala::draw could be used (Cala is my project that I would like to use these features for). wasmtime could possibly depend on it too or borrow some of the code from it in order to implement a "canvas" or "audio" module in the runtime. A current issue with that proposal at the moment, is that most of the cala APIs currently only work on Linux, but that will likely change in the (hopefully) near future.

Alternatives

I'm guessing there's a way to link a WASI program to a native program, with some FFI calls, say between a Rust program that includes wasmtime to run the web assembly (similar to just using the wasm32-unknown-unknown target). Although, at that point it would be fine to just use the wasm32-unknown-unknown target. I think it would be better if wasmtime included the additional modules.

Also, has any work been done to add any other modules besides WASI Core, that I am not aware of?

Wasmtime GitHub notifications bot (Jul 14 2020 at 16:41):

abrown commented on Issue #2015:

This may help: I'm working on a POC for an inference module, trying to follow the proposal process. I started by creating a draft spec, wasi-nn and proposing it in one of the WASI meetings. That was enough to get the idea into stage 0 (or 1? not sure) to start proving out the concept. That approach might help you with this idea.

Wasmtime GitHub notifications bot (Jul 14 2020 at 18:15):

AldaronLau commented on Issue #2015:

Thanks! This helped me find relevant issues to what I'm trying to accomplish: https://github.com/WebAssembly/WASI/issues/53, https://github.com/WebAssembly/WASI/issues/171, https://github.com/WebAssembly/WASI/issues/285.

Wasmtime GitHub notifications bot (Jul 14 2020 at 18:17):

AldaronLau edited Issue #2015:

In the readme, it says "Initially, the focus is on WASI Core, an API module that covers files, networking, and a few other things. Additional modules are expected to be added in the future."

I'm curious as to what it would take to start adding additional modules (I'm interested in contributing, and possibly helping design APIs outside of file management and networking).

Feature

Adding an API modules to cover something like a canvas (using JavaScript terminology), audio support, etc.

Benefit

Opens up possibilities to make graphics applications on WASI, or make a WASI virtual machine operating system (both are things I'm interested in doing).

Implementation

I think fairly minimal and simple asynchronous APIs inspired from cala::speaker/cala::microphone and cala::pixels/cala::draw could be used (Cala is my project that I would like to use these features for). wasmtime could possibly depend on it too or borrow some of the code from it in order to implement a "canvas" or "audio" module in the runtime. A current issue with that proposal at the moment, is that most of the cala APIs currently only work on Linux, but that will likely change in the (hopefully) near future.

Alternatives

I'm guessing there's a way to link a WASI program to a native program, with some FFI calls, say between a Rust program that includes wasmtime to run the web assembly (similar to just using the wasm32-unknown-unknown target). Although, at that point it would be fine to just use the wasm32-unknown-unknown target. I think it would be better if wasmtime included the additional modules.

Also, has any work been done to add any other modules besides WASI Core, that I am not aware of?

edit: A WebGPU-based API could work as a (probably better) alternative for graphics

Wasmtime GitHub notifications bot (Aug 02 2020 at 15:06):

jpryne commented on Issue #2015:

I've been very interested in this concept for some time, yet am not confident I could hammer it out alone. If you reach a point of having a one or more WebGPU features implemented, I'd be happy to study that code, deriving from it further functions towards completion.

Last updated: Oct 23 2024 at 20:03 UTC