Run LTLMoP compilation directly in browser, no API needed

[agilgur5]

Motivation

To make LTLMoPWeb3D fully client-side with no back-end API needed.

Summary

Nowadays, we can use newer technology like WebAssembly (WASM) and WASI to run native code directly in the browser. So we could compile LTLMoP's Python code to a WASI binary and run that in the browser instead of accessing an API.

Implementation Details

Specifically, I was looking at using container2wasm to convert the LTLMoP Docker image (from #42 / VerifiableRobotics/LTLMoP#82) to a WASI binary and then run it in the browser via either browser_wasi_shim or @runno/wasi.

The Spec Editor could then directly run the compilation commands in the browser instead of making API requests to the LTLMoP API.

Concerns

While LTLMoP is mostly Python, it also relies on Java code and native C and Fortran even (via numpy / scipy / BLAS). Each of those should be possible to compile to WASI, but there may or may not be problems getting them all to work together.

[agilgur5]

using container2wasm to convert the LTLMoP Docker image (from #42 / VerifiableRobotics/LTLMoP#82) to a WASI binary

This might not even be necessary with runno according to taybenlor/runno#321 (comment). Can directly use an OCI tarball

[coder0107git]

CheerpX or V86 might be interesting too. Although, I have some hesitations about recommending either one of them. CheerpX is proprietary and free for personal & open source use, while V86 seems challenging to use as a backend.

[agilgur5]

I'm aware of both those tools (see also my WASM / WASI list on GH) as I'm quite enthusiastic about WASM, WASI, the component model, etc, so actively follow it.
Regarding CheerpX, LTLMoP is not a single binary¹ and even getting it and all its dependencies into an isolated container took some effort way back when, so it wouldn't be straightforward to port onto CheerpX even if it were FOSS. Since LTLMoP is a research/academic tool and is licensed under GPLv3, there is some significance to FOSS usage too.
v86 would have some similar porting difficulties and also doesn't yet support 64-bit (can also see a comment of mine in that issue).

Porting the container image directly to WASM would be significantly more straightforward than either at this time. As an added benefit, a WASM binary could potentially be run directly on robot micro-controllers too given its portability (both this project and LTLMoP itself can connect to ROS services already, for reference).

Footnotes

1. as of right now at least, although I'd like to potentially get it to that state at some point too, especially for accessibility / ease-of-use and software preservation purposes. it needs both a Python and Java runtime plus all its deps right now, which was one of the reasons why the container format was quite useful back when ↩