Component Model /

WASI update

June 6, 2024

Agenda

• Preview 2
• Revisit/update timeline from last time
• What’s next
• Revisit WASI standardization question

Preview 2

• Developer Preview milestone, released in January
• Provides a stable point for producer/consumer toolchains
• The goal is to enable a lot more usage and feedback
• Proposals covered:
• Component Model:
• Language-agnostic composable packaging format for core wasm
• https://github.com/WebAssembly/component-model/
• WASI:
• A modular collection of standard interfaces to provide portability outside the browser
• Spec-wise, layered on top of the Component Model
• https://github.com/webAssembly/wasi
• https://github.com/webAssembly/wasi-*

Preview 2 - Component Model includes…

• High-level language-agnostic types at component boundaries
• Value types (numbers, strings, lists, records, variants and specializations thereof)
• Resource types (abstract types with a lifetime) + handle types (reference types with ownership)
• Human-friendly IDL (called “WIT”):
• Mirrors C-M types; defined via elaboration into component types (“WIT” = “WIT Is Types”)
• “interface” ⇒ component instance type, “world” ⇒ component type
• Related interfaces/worlds are grouped into publishable, versioned WIT “packages”
• WIT packages are just component binaries, using only the type section
• Regular name scheme: namespace:package/interface-or-world
• WIT packages can reference each other via “use” of ^^ names
• Linking
• Both shared-everything and shared-nothing, at the same time…

Preview 2 - Component Linking

.c

.o

.c

.o

.a

.a

…

core�module

…

core�module

component

component

…

component

“shared-everything linking”

“shared-nothing linking”

“static linking”

“dynamic linking”

.wit

.h

type.o

(component type embedded in custom section)

Preview 2 - WASI includes…

• wasi:clocks
• wasi:random
• wasi:filesystem
• wasi:sockets
• wasi:cli
• wasi:http
• Runtimes can implement any subset of these (alongside non-WASI interfaces)

Preview 2 - Related standard proposals

• In the CNCF (wasm-wg): Wasm OCI Artifact
• https://tag-runtime.cncf.io/wgs/wasm/deliverables/wasm-oci-artifact/
• Can be thought of as a third “representation” of a module or component
• Alongside single-file .wat and .wasm
• No runtime semantics!
• Benefits
• Can explode a single-file .wasm into N “layers”, de-duped by content hash (> blob store)
• Widely implemented storage/distribution standard (in clouds and open source impls)
• Lots of existing workflow integrations (metadata, signing, CI/CD, …)
• Starting to use for public registry backends
• Including WIT packages, e.g. ghcr.io/webassembly/wasi-http:0.2.0

Preview 2 - Implementation status

• Producer toolchains
• Pretty far along:
• Rust, JS, Python, Go
• WIP:
• .NET, Swift, Kotlin, C/C++
• Consumer toolchains
• Generic runtimes
• Pretty far along:
• Wasmtime, jco transpile, VSCode, wasm_component_layer
• WIP:
• WasmEdge
• Embedded SIG created in Bytecode Alliance to evaluate in embedded context
• Higher-level runtimes (embedding the generic runtimes)
• NGINX Unit, containerd/runwasi, wasmCloud, Spin, FastEdge
• Key: standards open the door to upstreaming

Developer Preview plan -- timeline (aspirational)

From the Oct 2023 CG presentation:

Platforms release Preview 2 support

Platforms release Preview 3 support (either alongside Preview 2 or converting 2→3, or first one then the other)

Same as before

but X+1

Start advancing C-M in the CG

(starting with Stage 2)

Developer Preview plan -- timeline (aspirational)

Updated:

What’s next

• WASI 0.2.1
• Just adding wasi:clocks/timezone
• Most of the work is figuring out how to do smooth versioning
• e.g., added @since / @unstable “gates” in WIT
• WASI 0.2.*:
• wasi:keyvalue
• wasi:runtime-config
• wasi:blobstore
• wasi:messaging
• wasi:gfx / wasi:webgpu
• wasi:i2c
• wasi:usb
• wasi:nn

What’s next

• Continued support for Preview 1
• Many deployed runtimes
• Don’t delete from producer toolchains (esp. wasi-sdk/wasi-libc)
• Maybe create Preview 2→1 converter tool
• Preview 1 is frozen
• But what if I have a core wasm engine (components not implemented/needed) but want to access the new Preview 2 functionality?

What’s next

• Add a core module “target” to Preview 2

<:

<:

wasm-tools�component�new

^^ both official Preview 2 “targets”

or: GOOS=wasip2 -buildmode=module|component ☃

package wasi:cli;

​

world command {

import wasi:filesystem/types;

…

}

(plan of record since day 1)

What’s next

• Preview 3:
• Wasm I/O 2024 talk
• Goals:
• Automatic language bindings to native language features (async, promises, goroutines, …)
• More efficient streaming ABI (most of what folks when they say “shared memory”)
• Composable concurrency
• Avoid the “What color is your function (component)?” problem
• Compatible-with but not dependent-on stack-switching (just like JSPI)
• Polyfillable in browser via core wasm + JS API + JSPI
• Progress:
• First chunk of functionality: https://github.com/WebAssembly/component-model/pull/363
• wasi-http 0.3 draft: https://github.com/WebAssembly/wasi-http/tree/main/wit-0.3.0-draft
• Demo implementation in https://github.com/dicej/component-async-demo

WASI standardization question

• Last time, an open question:
• The Component Model fits into the CG’s existing charter/process. WASI… not so clear
• Since then, lots of good feedback:
• Component Model is now included in official WebAssembly WG charter
• WASI perhaps deserves a wholly new W3C CG+WG pair
• Chatted with our W3C liaison Mike Smith and no red flags
• What would the scope of a new WASI WG be, though?
• We’re not trying to define a single monolithic set of low-level APIs available everywhere
• More like the opposite: lots of domain-specific APIs (cloud, mobile, embedded, DB, edge, …)
• … but does that lead to an unbounded scope?
• Perhaps:
• Define bindings to existing (de facto or de jure) standards
• The WG’s job is to pull in domain experts to evaluate the bindings for suitability
• … which is what we’ve actually been doing
• We’re still far from a “1.0”, but it’s good to pipeline this discussion