jcoffey-dev
136fc2540b
tools/sieve-playground builds the vendored sieve-rs 0.7.3 (vnd.inbuxa.* names included) to WebAssembly, with a static page around it, for inbuxa Admin's Debug button on a Sieve script: until now that button sent the script to an outside site whose interpreter knows only upstream's extension names, so any script that requires vnd.inbuxa.* failed to compile there. Ported from the playground in the upstream sieve-rs repository's web/ directory (commit 549a2d57f7), which targets sieve-rs 1.x: - run.rs and handler.rs drive 0.7's event loop the way the server's delivery does, carrying on after a runtime error; llm_prompt compiles and answers false, as on a server without a model. - The expression functions are the server's own modules, included by path; tests fail if the list, ApplyString or the few functions copied from misc.rs/unicode.rs stop matching crates/common. - Built for wasm32-wasip1 rather than with wasm-bindgen: sieve-rs and mail-builder read the clock, which panics on wasm32-unknown-unknown. The page's worker answers the six WASI calls, giving the module the playground's current-time setting. shim/gethostname stands in for a crate with no WASI build. Nothing in vendor/ or crates/ changes. - The page carries no upstream names or links; storage keys and the samples are renamed to match. build.sh --admin <dir> stages the result into an inbuxa-admin checkout.
Sieve playground
A browser-only playground for Sieve scripts, shipped inside inbuxa Admin: the
Debug button on a Sieve script opens it there with a copy of the script.
It compiles and runs scripts with this repository's own Sieve interpreter,
compiled to WebAssembly, so a script behaves as it does on the server: the
same sieve-rs (vendor/sieve-rs, with the vnd.inbuxa.* extensions) and the
same expression functions an account script can call. Scripts, messages and
settings stay in the browser.
Ported from the playground in the upstream sieve-rs repository's web/
directory (commit 549a2d57f7), which targets sieve-rs 1.x.
Layout
src/lib.rs: the module's one export,playground_call, JSON in and out:version,capabilities,defaults,compileandrun.src/run.rs: compiles the main script and the include tabs and drives the interpreter's event loop the way the server's delivery does, carrying on after a runtime error.src/handler.rs: answers the interpreter's events from the settings and records the actions.src/functions/: the server's own function modules (crates/common/src/scripts/functions), included by path; tests fail if the playground's list stops matching the server's account-script list.src/settings.rs: compiler and runtime options. The defaults are permissive; the server's limits for account scripts are lower.site/: the static page and its ES modules.worker.jsruns the module off the main thread and gives it the WASI calls it makes.shim/gethostname: stands in for a crate with no WASI build.
Why WASI
sieve-rs 0.7 and mail-builder read the clock with SystemTime::now(), which
panics on wasm32-unknown-unknown. Built for wasm32-wasip1, they ask the
host for the time instead, and worker.js answers with the playground's
current-time setting, so currentdate and the Date of a vacation reply
follow it. The module needs six WASI calls, all in worker.js.
0.7 does not count the instructions a run executes, and has no memory limit, so the playground shows neither.
Build
./build.sh # target/site
./build.sh --admin ../inbuxa-admin # inbuxa-admin/sieve-playground
It runs the tests, builds the module and stages it with site/. It needs the
wasm32-wasip1 Rust target. inbuxa Admin's build copies the staged directory,
with Monaco from its own node_modules, into a directory named after a hash
of its contents, so an Admin release never serves a stale copy.
When vendor/sieve-rs or the server's function modules change, rebuild with
--admin and commit the result in inbuxa-admin.