With the interest in porting Avogadro to the web, and in the interests of opening up plugin development to more languages, how viable would it be for us to introduce an embedded WASM interpreter into Avogadro?
Python is going to remain the natural choice for people to develop plugins, of course, but if we could support WASM as well we’d basically be supporting any language that an author might like to use.
Unlike stand-alone binary plugins, which couldn’t really be distributed via Avogadro’s infrastructure and the plugin manager due to the security issues that arise, it’d presumably be much more feasible to distribute WASM plugins in a safe way; I assume it’s common practice to sandbox the WASM virtual machine, for example.
Embedded? That seems tricky. I do think there are cross-platform tools for running WebAssembly on the command-line like wasmtime which is also available on conda-forge.
But while I can understand someone wanting to run a binary, I’m not sure what WASM gets you (besides a sandbox) - or how much interest there would be for this (vs. running a binary).
Personally I’d be more inclined to look at images - Docker, Singularity, etc. since those could enable cross-platform binaries.
Well, WASM as a plugin engine is increasingly common, I believe (or at least, it is commonly suggested).
The sandboxing is the main thing it does get you over binaries, in my view. I’m not sure there is any realistic way we could allow people to distribute binaries via the centralized index/plugin manager without implementing some build infrastructure and compiling them from source ourselves to ensure they are what they purport to be.
Meanwhile, WASM plugins would have the same benefits as binaries: performance and language agnosticism.
So I see WASM as a route to providing plugins that are effectively binaries while being less of a security risk, such that we can distribute them.
One solution I have come across before when considering how to implement plugins in my own project is Extism, which has an officially supported C++ SDK. It promises full sandboxing. The way Extism handles plugin communication seems suitable for our JSON-based API.
I guess my feeling is that we should build this out when there’s a clear use case and we’re not likely to get too many existing compchem binaries compiled for WASM.
IIRC a lot of supercomputing / HPC systems want something like Singularity if you’re bringing a binary rather than their pre-installed software.
I guess what I’m saying is that, for the Avogadro audience (compchem) I would guess there are more users familiar with putting together Docker or Singularity or similar image tool. So if we’re looking for “safe sandbox for binaries,” that would be where I would start (albeit with some sort of survey to figure out what people are actually using).
Now if there’s some sort of easy method to take an existing binary (e.g., for Linux) => WASM then I could see some way to offer a tutorial “how to distribute binaries for Avogadro plugins.”
I thought of a third option, which is “you can run binaries from trusted sources,” e.g. conda-forge or other trusted community repository.
I looked into the image side - it’s a pain for Mac users because you need Docker Desktop to spin up an x86-64 Linux VM for any binary. Maybe a few people have it, but seems like limited use.
I also found elfconv which might be worth watching, but it currently only supports ARM-64 Linux binaries, not x86-64 and has big warnings about being a work in progress.