Michael Herman (Trusted Digital Web)

For developers who wish to use WASI on specific hardware can set a software flag, which will tell the WASI runtime to run the bytecode for a particular platform, allowing the program to get access to a file system, or to a virtual file system.

But WASI is fostering other, faster and more portable options, Clark explained in her talk.

One is the WASI File System interface, in which WASI offers its own virtual file system to the developer. In this approach, the developer would open and read files using the same calls, but the files themselves would reside entirely within WASM module.

“This means that we don’t have that global shared mutable state problem that the file system introduces. Even though these look like files in the source code, under the hood, they would use WASI I/O types, things like streams and arrays, that would give them that full portability,” Clark explained.

The downside to this approach is that size of the modules would balloon, given the virtual file system each WebAssembly module would be carrying.

For full portability and efficiency, a third API, known as WASI I/O, could be used. In this case, the program would not call files at all, but more specifically the pointers to the I/O types themselves, such as data arrays or strings. “And with this, the developer no longer even thinks in terms of files. It’s all just these pure I/O types,” she explained.

Get Outlook for Android