What would you use this for? I don't get the whole picture and the article doesn't talk about it.
This enables a new set of possibilities for Wasm and SQLite. For example, now you can run a full WordPress application in the browser [1][2] / server [3] using the same Wasm module. Note that for the browser these projects use Emscripten [4], but in the future the same Wasm32-wasi module will work. A teammate gave a lightning talk about SQLite and WASI at KubeCon EU [5].
In general, any environment that includes a wasm runtime can potentially run applications that uses SQLite under the hood. Before, it wasn't possible.
- [1] https://wordpress.wasmlabs.dev/
- [2] https://developer.wordpress.org/playground/demo/
- [3] https://wasmlabs.dev/articles/running-wordpress-with-mod-was...
- [4] https://emscripten.org/
I'm curious to know more about this. Does it mean that when browsers support WASI, these projects will not need to use Emscripten? Or maybe use it for compiling to/with WASI but without the need for a runtime anymore.
Is there anywhere I can keep track of when/how this might happen?
- Use a library that provides the WASI bindings in a browser environments: there are some OSS projects that provides WASI bindings on top of browser technologies. For example, workers-wasi from Cloudflare [1]. It could be even another Wasm module that provides the implementation for the main one. I know the people from Loophole Labs are experimenting with virtual filesystems (VFS) [2].
- Browsers provides a WASI implementation: server-oriented runtimes like NodeJS are already providing these bindings (under a experimental flag). I shouldn't have stated that as a fact, as browsers may provide it or not. However, I saw in the past the Google Chrome team experimenting with WASI and the browser FileSystem API [3]. So, I think it may happen :)
- [1] https://github.com/cloudflare/workers-wasi
In practice, this means that you can compile your Rust/C++/etc code to WASM + WASI, and that code will run anywhere you have a WebAssembly VM. So the same code that accesses the "filesystem" in a browser context can also access the filesystem in a desktop/mobile/edge/etc environment.
You could also think of it as an attempt to turn WebAssembly into a fully-fledged JVM alternative. Compile once, run anywhere (including browser).
For this specifically, it means that SQLite can integrate with WASI APIs (instead of only Web APIs as before) so that an SQLite Wasm build can run in other contexts besides browsers.
How much "batteries included" is this runtime (planned to be)? If I understood this correctly, then there would be a tradeoff with having more batteries included which would imply more functionality for applications but make porting to new targets more work.
In the future, the WASI standard will include more and more features. This will allow SQLite to enable more internal features that are currently skipped due to the limitations on WASI.
A lot of the sandboxing and security focus in Wasm makes sense. But the "capability-based security" mentioned at WASI spec [0] confuses me. For instance, when looking to what Cosmonic (an early adopter in Wasm fields) documents as capabilities [1] (e.g. 'messaging', 'http client', 'key-value store') it seems wholly different to concepts from the E programming language [2] by Mark S. Miller, that are finding their way in Cap'n Proto [3] and early work on the OCapN [4] unification effort. Is there any relationship to these, or are we looking at totally different approaches? Or is Cosmonic overloading the terminology of "capability"?
[0] https://github.com/WebAssembly/WASI#capability-based-securit...
[1] https://cosmonic.com/docs/category/capabilities
> Perhaps most importantly, role-based access control and attribute-based access control, and other authorization and access control technologies, can introduce complex external systems that must be synchronized with the plugin as well as the underlying server-side technology. In contrast, Wasm access control capabilities are often built directly into the runtime engines, reducing the complexities and simplifying the development process.
However, my understanding is that WASI itself is actually capability-based, and I think your link [0] is thinking about capabilities in the right way. In fact I'm pleased to see "Interposition" seems to have been added here, IIRC a few years ago that was missing and I feel it's an essential piece of capability-based security.
As an example, in WASI, there is no singleton filesystem, instead the application receives a set of file descriptors for specific directories which grant access only to those directories and their children, not their parents. Though last I looked, the libc wanted to reconstruct those into a single virtual filesystem, assigning each one a mount point and matching paths against those, in the name of compatibility, which felt unfortunate to me.
As always, a lot of people struggle to "get" capabilities, even when they are building on top of a platform designed around the idea. :/
(sqlite team's Wasm/JS guy here)
That's the long and the short if it. We currently _actively_ target browsers only because our team has exceedingly limited bandwidth and has to be choosy with regards to where our dev time goes. Long-term, we intend to target all wasm platforms, but getting there is an ongoing process.
Although it was a bit of a surprise to see that they started out with the toy CLI tool that my self and Nicholas hacked on for a weekend (I wanted to be able to run SQLite commands in a-Shell, which is an excellent iPad CLI environment).
> We wanted to contribute upstream our patches for SQLite, as we were heavily relying on libsqlite for our tests of PHP.wasm with WordPress and Drupal.