The fact that wasm is sandboxed allows some genuinely new things. Imagine a JSON file starting with a line that gives a base64-encoded WASM parser for JSON. (Or a hash on a public database if you're worried.) Switch to YAML or TOML by changing that line up top, or add comments to your JSON, or get fed up and ship SQLite databases instead. Oh wait I have security concerns, I need to encrypt this file at rest, better change the code that consumes it—why? The registry has a NaCl container, just prefix the encrypted version with the wasm hash to prompt for a password and decrypt it.
It’s a technique that used to be popular and then died out as networks proliferated—you could no longer be sure that your machine code did the right parse on someone else's architecture.
Your container crashes and we coredump to an S3 bucket. You know what’s better than downloading gigabytes of coredump? If S3 can just let you spin up a container or run a WASM program on the storage node itself. You send the programs to the data so you don't need to pull the data to yourself.
This post describes something like Erlang actors, but if each can be a pure function encoded in WASM... That is also a neat dream. But the next step is the MonadArrow instance, programs sending programs to each other. Then we’re “thinking with portals.”
> It’s a technique that used to be popular and then died out as networks proliferated—you could no longer be sure that your machine code did the right parse on someone else's architecture.
This will be the case with WASM extensions. You won't be sure what's available in someone else's WASM environment.
The only reason it's not the case with WASM on the web today is because it's so simple, and any differences are dealt with in the JavaScript layer.
> Your container crashes and we coredump to an S3 bucket. You know what’s better than downloading gigabytes of coredump? If S3 can just let you spin up a container or run a WASM program on the storage node itself.
S3 literally has this feature, and it doesn't even have to be WASM. It's called "S3 Object Lambda". It's quite new, so you're forgiven for not knowing about it.
Downloading from S3 is quick and free if it's within the same region, so you don't actually need this anyway.
The fact that wasm is sandboxed allows some genuinely new things. Imagine a JSON file starting with a line that gives a base64-encoded WASM parser for JSON. (Or a hash on a public database if you're worried.) Switch to YAML or TOML by changing that line up top, or add comments to your JSON, or get fed up and ship SQLite databases instead. Oh wait I have security concerns, I need to encrypt this file at rest, better change the code that consumes it—why? The registry has a NaCl container, just prefix the encrypted version with the wasm hash to prompt for a password and decrypt it.
It’s a technique that used to be popular and then died out as networks proliferated—you could no longer be sure that your machine code did the right parse on someone else's architecture.
Your container crashes and we coredump to an S3 bucket. You know what’s better than downloading gigabytes of coredump? If S3 can just let you spin up a container or run a WASM program on the storage node itself. You send the programs to the data so you don't need to pull the data to yourself.
This post describes something like Erlang actors, but if each can be a pure function encoded in WASM... That is also a neat dream. But the next step is the MonadArrow instance, programs sending programs to each other. Then we’re “thinking with portals.”