ovf (Mar 14 2024 at 09:58): ovf (Mar 14 2024 at 09:58):i probably asked something similar in the past, but i'll try again in light of p2:
i'd like to have the same binary work in- and out of browser, but have access to additional functionality in the former case, and detect its absence at runtime in the latter case.
at least in the past i think there was no equivalent to weak symbols or unimplemented syscalls, so i've seen people resort to some rather fanciful hacks like hardcoded virtual files for communication.
has the state of the art moved in p2?
Tarek Sander (Mar 14 2024 at 10:15):In a runtime, you can provide implementations for a WIT interface, and in the browser you can let jco map it to a JS implementation, and that can also just be a no-op implementation that returns an error. I don't know how exactly it's done though.
bjorn3 (Mar 14 2024 at 10:36):I believe OP wants to provide extra interfaces in the browser while still working outside of the browser in an existing wasi runtime, not the other way around.
Tarek Sander (Mar 14 2024 at 10:36):The process to do that is the same though.
bjorn3 (Mar 14 2024 at 10:38):You can't have the extra syscalls return an error outside the browser without modifying the wasi runtime (eg writing your own executable which uses wasmtime-wasi as crate). As I understand OP wants it to work with an unchanged wasi runtime (eg the official wasmtime builds).
ovf (Mar 14 2024 at 10:39):yes, thanks @bjorn3
Tarek Sander (Mar 14 2024 at 10:44):In that case, virtual files would be one option. I think the nicer thing would be another preopen in addition to stdin, stdout and stderr. That way you can have a pipe to connect with whatever other side. On the web you can have a handler for reads and writes to the stream, and for a runtime you can pass the path to a filesystem pipe.
Alex Crichton (Mar 14 2024 at 14:11):Currently there is no implementation or design for optional imports, so I believe that the state of the world is the same as before. Lots of folks still interested in it, just no implementation/design yet
ovf (Mar 14 2024 at 14:40):thanks @Alex Crichton! i suspect my use case could also be served by dynamically loaded (modules? components?), but i understand their implementation is roughly in the same state, per https://github.com/WebAssembly/component-model/blob/main/design/mvp/examples/SharedEverythingDynamicLinking.md
Alex Crichton (Mar 14 2024 at 14:40):shared everything dynamic linking is I don't think implemented exactly as specified there but componentize-py is built on a more-or-less equivalent, so that part is more "real" of sorts today
ovf (Apr 05 2024 at 16:46):sorry, completely forgot to say thanks! haven't had a chance to fully understand what componentize-py is doing, but still i'm quite interested in improving these things (i understand you guys are busy with p2 at the moment)
Last updated: Nov 22 2024 at 17:03 UTC