Task #3329
Updated by Jason Ish about 5 years ago
This ticket is to capture thoughts and research about using WASM for: * A Lua alternative: matching and outputs (where Lua is used) * As a module format for dynamically loadable modules/plugins WASM as a Lua Alternative * WASM modules run in a very restrictive execution environment where they cannot access the network, files, etc. * This might be OK for pure algorithmic uses, such as a module that calculates entropy. * But is not suitable if the module requires access to external files, either to read in data from an external source (for example in a Lua rule), or writing to a custom log file (a Lua output). * WASM also requires more overhead on the authors part. Once they have chosen a lanuage, they will have to configure their toolchain to output WASM. While in some cases this may be trivial, it is more overhead than writing a Lua script. WASM for Dynamically Loadable Modules * WASM may be more interesting for dynamically loadable modules, but its restricted environment may not make that very popular. * From my understanding it would not be possible to implement a custom database or Kakfa style output as a WASM module. However I could be wrong as I've seen examples of Nginx recompiled to WASM, so more research is required here. * Its restrictions may make it not popular as a format for dynamically loadable modules, however the strict environment it runs in would be nice. But writing native plugins in Rust and loading as a .so will ultimately be more flexible (but not sandboxed). less secure). WASM outside of the browser also appears to be very young and rapidly evolving. I also found AssemblyScript (https://github.com/AssemblyScript/assemblyscript) interesting. This is a compiler for a subset of TypeScript that compiles to WASM.