1 of 3

Background

  • CG-04-27: Scoping and Layering the Module Linking and Interface Types proposals
    • Module linking should be factored out into a layer above core wasm
    • Interface Types would be simpler as an extension of Module Linking
    • This suggests a new (layered) spec with feature additions over time (like the core spec)
    • What should the scope (goals, use cases, requirements) be?
    • Proposed scope: a Lightweight Component Model
    • Proposed next steps
  • design/#1415 filed for follow-up discussion
    • Positive reaction on the general direction
    • Questions/discussion about proposed next steps
  • Polls for today’s agenda:
    • Does the proposed general direction sound good?
    • Should we proceed with the proposed next steps?

2 of 3

Poll 1: Does the proposed general direction sound good?

Summary of “general direction”:

  • Start a new “Component Model” spec layered on top of the Core spec
    • With Module Linking and Interface Types as the first two proposed additions to the spec
  • High-level goals:
    • Cross-language/toolchain composition, without requiring an additional ABI on top
    • Shared-nothing, with each language/toolchain encapsulating its own core wasm mutable state
    • Embeddability, allowing component runtimes to be embedded in a wide variety of hosts (incl. browsers)
    • Virtualizability, with all imports implementable by component exports and no shared namespaces
    • Static analyzability, leaning into imports instead of ubiquitous runtime virtual dispatch
  • Out of scope:
    • Distributed computing (partial failure, networking, RPC, actors, queues, live upgrade, deployment, …)
    • “Component services” (persistence, storage, discovery, naming, caching, pooling, …)
    • All of these are important, but often domain-specific and better solved at a higher level
      • … and many in the wasm ecosystem are working on wasm platforms solving these problems (in different ways)
      • The hope is that they can all meaningfully embed components (wins: shared tooling, language agnosticism, nice properties⤴)

3 of 3

Poll 2: Should we proceed with the proposed next steps?

  • Proposed next steps:
    • Create a new component-model repo to serve the same role as the Core design+spec repos
      • Add HighLevelGoals.md, UseCases.md, Requirements.md, FAQ.md based on slides
    • Rebase module-linking from spec to component-model; continue linking-specific discussions
    • Rebase interface-types onto module-linking (factoring out adapter_module et al.)
    • Split out “adapter functions” from interface-types into new adapter-functions proposal repo
    • Add “canonical ABI” to interface-types (draft in PR interface-types/#132)
  • Why the adapter function / canonical ABI change?
    • Adapter functions are ultimately just an optimization vs. a fixed (de)serialization format
      • Which is what everyone else is doing right now, hence this is a natural “MVP”
    • Adapter functions has a long way to go as a feature but we need components “now”
    • The canonical ABI is valuable even after adding adapter functions
  • Not covered by poll:
    • The exact set of interface types and their semantics (handles and buffers are still incoming)
    • The exact canonical ABI (including string encoding), just the intention to design one