Component Model /

WASI update

October 12, 2023

Agenda

• Background
• “Developer Preview” plan
• Why
• How
• Timeline
• Preview 2
• What’s covered
• Implementation status/interest
• Preview 3
• What’s next?
• Open questions regarding standardization process

Component Model Background

• Introductory resources:
• github.com/WebAssembly/component-model
• component-model.bytecodealliance.org
• What is a Component (and Why)?
• tl;dr:
• A component is standard, portable, lightweight, finely-sandboxed, cross-language, compositional module
• High-level use cases:
• Automatic generation of high-level source bindings from a language-neutral IDL
• Cross-language code reuse and composition
• Strong modularity/isolation between subsystems/layers of large applications

WASI Background

• Now rebased on the Component Model!
• No longer a single monolithic “system interface”
• A modular collection of virtualizable interfaces defined in WIT (Component Model IDL)
• A component can import/export 0..N WASI interfaces (but also non-WASI stuff too)
• s/WebAssembly System Interface/WebAssembly Standard Interfaces/
• For example, see wasi-virt
• Enable interoperability/portability, but acknowledge inherent heterogeneity of wasm landscape:
• Browser, client app, embedded, server (cloud ↔ edge), “plugin” (DB, stream, CDN, SaaS)
• Not trying to find some generic intersection/union of all these
• Proposals:
• From Preview 1, now modularized: IO (async), clocks, random, filesystems, CLI
• New and active: sockets, crypto, machine learning (NN), HTTP, keyvalue
• Full list: github.com/WebAssembly/WASI/blob/main/Proposals.md

Developer Preview plan

• We’ve by now built out quite a lot of this
• Runtimes, tools for producing, composing, publishing, etc
• Really need a way to ship it to collect and incorporate wider feedback
• More than just unit tests and demos from core contributors
• But we still need the ability to make (breaking) changes based on feedback
• We had similar question leading up to WebAssembly 1.0
• 2016 WebAssembly “Browser Preview” release ^1,2,3
• How do we do this outside the browser?
• We don’t have “the 4 popular browsers”
• … with the mechanisms of: prefs, release channels, origin trials
• But we also don’t have millions web developers
• … who will immediately depend on whatever we release
• … and not update their content
• Which suggests a more traditional versioned approach

Developer Preview plan -- how?

• Explicitly version:
• the Component Model (version in the preamble world, like the Browser Preview)
• each WASI proposal (as part of the import/export name)
• Define a “Preview X” release to cover:
• A single Component Model version fixed for the duration of Preview X
• A version of each individual WASI interface…
• … but only covering a subset of the WASI proposals
• Only WASI proposal that meet a certain criteria (incl. having multiple implementations)
• The subset can grow as new WASI interfaces satisfy the criteria
• WASI interfaces in the subset can bump minor version (making compatible additions)
• Build reusable tooling to automatically migrate Preview X to X+1
• Worst-case: low-level rewrite+link (e.g., the Preview-1-to-2 adapter)
• Easier: pure component virtualization (hopefully: Preview-2-to-3 adapter)

Developer Preview plan -- timeline (aspirational)

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)

Preview 2: what’s covered?

• Component Model
• Linking (of components and modules), value types (lots), resource+handle types (own+borrow)
• WIT (IDL), and encoding of WIT into component binary (type sections)
• Initial set of WASI interfaces
• Interfaces: Clocks, Random, IO, Filesystem, Sockets, CLI, HTTP
• Worlds: wasi:cli/command and wasi:http/proxy
• Likely interfaces over the next year:
• Key-value store (several varieties: durable+eventually-consistent, session-local, cache, …)
• Blob store
• Crypto
• NN?
• Messaging?
• …?

Preview 2: implementation status / interest

• Wasmtime: Preview 2 almost done
• WasmEdge: started implementing Preview 2 (tracking issues)
• containerd-wasm-shims (used by K8s + Docker Desktop): uses Wasmtime+WasmEdge
• jco transpile (browser polyfill): Preview 2 well underway
• VSCode (as a WASI runtime): supports Preview 1, started Preview 2 (maybe w/ jco)
• Platforms publicly contributing to shared Preview 2 implementation:
• Fastly Compute: embeds Wasmtime, implements custom WASI HTTP
• Microsoft AKS: embeds containerd-wasm-shims to run wasm Deployments
• Fermyon: open-source Spin runtime embeds Wasmtime
• Cosmonic: open-source WasmCloud runtime embeds Wasmtime
• Leading languages: JavaScript, Rust, Python, Go, C

Preview 3: what’s next

• Additions to the Component Model
• “native” async
• Adding future and stream types to the Component Model + WIT
• Enable usable automatic source bindings
• Provide an efficient low-level ABI (obviate many seeming use cases for shared memory)
• Semantically layered on stack-switching (in the same manner as JSPI)
• Design sketch
• Refactor Preview 2 WASI interfaces to use future and stream types
• optional imports/definitions/exports
• c.f. conditional-sections/#22
• better error/logging support
• Additional WASI interfaces
• Based on Preview 2 Component Model, so we can develop in parallel with async
• Additional languages (bindings generators)

Open questions regarding standardization

• Component Model is “pure compute”, just like WebAssembly
• No built-in I/O → only imports (just like Core WebAssembly)
• Easy to see how to:
• Layer Component Model spec onto the Core WebAssembly spec
• extend the JS API to components (both imperative API and ESM-integration)
• WASI is a different story
• All about I/O
• Crosses the chasm from “polyfillable via JS” into “Web API” territory
• Browsers are much more protective of API territory
• In general, polyfilling/virtualization is a valid and intended WASI implementation strategy
• Thus, a standardized interface is valuable even if not implemented “natively”
• What’s the right standards process / venue?
• The W3C seems broad-enough in scope, but is the WebAssembly CG/WG?
• We have several years to figure this out; I just want to start the discussion now