From fa99a79c3e5bafdaa550454ab09fd6f29724f060 Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Mon, 21 Jul 2025 14:15:55 -0700 Subject: [PATCH 01/29] Revise and expand on 'Component Model Concepts' section and its subsections --- .../src/design/component-model-concepts.md | 105 +++++++++++++++--- component-model/src/design/components.md | 53 ++++++++- component-model/src/design/interfaces.md | 50 ++++++++- component-model/src/design/packages.md | 15 ++- .../src/design/why-component-model.md | 4 +- component-model/src/design/worlds.md | 86 ++++++++++++-- 6 files changed, 275 insertions(+), 38 deletions(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index d5c6789c..216c7e0c 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -1,30 +1,101 @@ ## Component Model Concepts -This section introduces the core concepts and [rationale](./why-component-model.md) of the component model. - -* A [WebAssembly Component](./components.md) is the next evolution of core WebAssembly binaries. - * WebAssembly components are *nestable* -- they may contain one or more core modules and/or sub-components composed together. -* The Component Model extends core WebAssembly by introducing higher level types and interface-driven development - * [WebAssembly Interface Types (WIT)][wit] is the [IDL (Interface Definition Language)][wiki-idl] used to formally define functionality for WebAssembly modules. - * With WIT, WebAssembly components gain the ability to conform an language-agnostic and encode that support, so any WebAssembly component binary can be interrogated *and* executed. - * An [Interface](./interfaces.md) describes the types and functions used for a specific, focused bit of functionality. - * A [World](./worlds.md) assembles interfaces to express what features a component offers, and what features it depends on. - * A [Package](./packages.md) is a set of WIT files containing a related set of interfaces and worlds. -* The Component Model introduces the idea of a "platform" to core WebAssembly -- enabling the structured, standardized use of "host" functionality for WebAssembly "guest"s. - * The WebAssembly System Interface (WASI) defines in WIT a family of interfaces for common system-level functions. - * WASI defines common execution environments such as the command line (`wasi:cli`) or a HTTP server (`wasi:http`). -* The Component Model makes core WebAssembly composable -- components that provide functionality and those that use them can be composed together into *one* resulting component +The WebAssembly Component Model extends core WebAssembly +by introducing higher-level types +and interface-driven development. +The Component Model makes core WebAssembly composable: +components that provide functionality and those that use them +can be composed together into *one* resulting component. + +This section introduces the core concepts behind the component model. +For the rationale behind the component model, see [the previous section](./why-component-model.md). + +### Components + +A [WebAssembly Component](./components.md) is a core module extended with higher-level types and interfaces. +WebAssembly components are *nestable*: +they may contain one or more core modules and/or sub-components composed together. +For example, a component implementing a simple calculator might be written +by composing together a component that parses strings to floating-point numbers +with a component that does the main arithmetic. + +### WebAssembly Interface Types (WIT) + +[WebAssembly Interface Types (WIT)][wit] is the [IDL (Interface Definition Language)][wiki-idl] +used to formally define functionality for WebAssembly modules. +WIT gives WebAssembly components the ability to express type signatures +in a language-agnostic way, +so any component binary can be both checked and executed. + +### Interfaces + +An [_interface_](./interfaces.md) is a collection of type definitions +and function declarations (function names accompanied by type signatures). +Typically, a single interface describes a specific, focused bit +of functionality. +For example, in [wasi-cli][wasi-cli-stdio], +three separate interfaces are used to implement `stdin`, `stdout`, and `stderr` +(the three input and output streams typically available +in a command-line environment.) + +### Worlds + +A [_world_](./worlds.md) is a collection of interfaces +that expresses what features a component offers +and what features it depends on. +For example, wasi-cli includes the [`stdio` world][wasi-cli-stdio], +which collects together three separate interfaces +that represent the `stdin`, `stdout`, and `stderr` streams. +Any component implementing the `stdio` world +must implement those three interfaces. + +### Packages + + A [_package_](./packages.md) is a set of WIT files + containing a related set of interfaces and worlds. + For example, the wasi-cli package includes + the `stdio` world and the `environment` world, among others, + with each defined in its own WIT file. + +### Platforms + +In the context of WebAssembly, the _host_ is the browser or stand-alone runtime +that runs WebAssembly modules. +The _guest_ is the WebAssembly module that is executed by the host. +(These terms come from virtualization, where a guest is +a software-based virtual machine that runs on physical hardware, +which is the "host") + +The Component Model introduces the idea of a _platform_ +to core WebAssembly—enabling the structured, standardized use +of host functionality for WebAssembly guests. + +## WASI + +The WebAssembly System Interface ([WASI][wasi]) defines in WIT +a family of interfaces for common system-level functions. +WASI standardizes the functionality provided by platforms, +so that component writers can rely on functionality +that is guaranteed to be available on any conformant platform. + +WASI defines common collections of functionality +such as the command line ([`wasi:cli`][wasi-cli]) +or an HTTP server ([`wasi:http`][wasi-http]). > [!NOTE] -> The Component Model is stewarded by the Bytecode Alliance and designed [in the open][cm-repo]. +> The Component Model is stewarded by the [Bytecode Alliance](https://bytecodealliance.org/) and designed [in the open][cm-repo]. > -> See the [`WebAssembly/component-model`][cm-repo] repository for [Goals][goals],[use cases][use-cases], and [high level design choices][design-choices]. +> See the [`WebAssembly/component-model`][cm-repo] repository for [goals][goals], [use cases][use-cases], and [high level design choices][design-choices]. [cm-repo]: https://github.com/WebAssembly/component-model -[wiki-idl]: https://en.wikipedia.org/wiki/Web_IDL +[wiki-idl]: https://en.wikipedia.org/wiki/Interface_description_language [goals]: https://github.com/WebAssembly/component-model/blob/main/design/high-level/Goals.md [use-cases]: https://github.com/WebAssembly/component-model/blob/main/design/high-level/UseCases.md [design-choices]: https://github.com/WebAssembly/component-model/blob/main/design/high-level/Choices.md [wit]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md +[wasi]: https://wasi.dev/ +[wasi-cli]: https://github.com/WebAssembly/wasi-cli/ +[wasi-cli-stdio]: https://github.com/WebAssembly/wasi-cli/blob/main/wit/stdio.wit +[wasi-http]: https://github.com/WebAssembly/wasi-http [!NOTE]: # diff --git a/component-model/src/design/components.md b/component-model/src/design/components.md index 53cfb1a4..bed86e6c 100644 --- a/component-model/src/design/components.md +++ b/component-model/src/design/components.md @@ -1,9 +1,52 @@ # Components -* Logically, components are containers for modules - or other components - which express their [interfaces](./interfaces.md) and dependencies via [WIT](./wit.md). -* Conceptually, components are self-describing units of code that interact only through interfaces instead of shared memory. -* Physically, a **component** is a specially-formatted WebAssembly file. Internally, the component could include multiple traditional ("core") WebAssembly modules, and sub-components, composed via their imports and exports. +Conceptually, a component is a self-describing unit of code +that interacts only through interfaces +instead of shared memory. +Let's break down what each of these terms means: -The external interface of a component - its imports and exports - corresponds to a [world](./worlds.md). The component, however, internally defines how that world is implemented. +* _Self-describing_: Like a WebAssembly core module, + a component includes import and export declarations + that declare both the names and types of + imported and exported functions. + Compared to core modules, components use a richer type system + to describe these types, so it's easier to understand + what functionality a module provides + and what functionality it relies on. +* _Interacts_: When a component interacts with other components, + that means either that it calls a function defined in a different component, + or that another component calls a function defined in it. + Interfaces specify what kinds of function calls are valid. +* _Shared memory_: In the ["Why the Component Model?"](./why-component-model.md) section, + we showed how WebAssembly core modules can only exchange compound data + through shared memory. + Components use memory in the same way that core modules do, + except that in components, memories are never exported or imported; + they are not shared. -> For a more formal definition of what a component is, take a look at the [Component Model specification](https://github.com/WebAssembly/component-model). +Logically, a component is a structure +that may contain core modules and/or other components. +The component encodes the interfaces of these contained +modules and sub-components using [WIT](./wit.md). + +The on-disk representation of a component +is a specially-formatted WebAssembly file. +Internally, this file could include representations +of one or many traditional ("core") WebAssembly modules +and sub-components, +`composed` via their imports and exports. +Two modules or components can be composed if the +imports of one are satisfied by the exports of another. +Composition can be repeated arbitarily, composing a +single component out of many interlocking modules and components. +[Interfaces](./interfaces.md) enable checking that +a particular composition makes sense. + +Each component is described by a [world](./worlds.md), +which potentially collects together multiple interfaces +to describe all the imports and exports of the component. +The world only describes the types of imported and exported functions; +the component internally defines the code to implement the world. + +> For a more formal definition of a component, +> take a look at the [Component Model specification](https://github.com/WebAssembly/component-model). diff --git a/component-model/src/design/interfaces.md b/component-model/src/design/interfaces.md index 69f3c573..e3341b0c 100644 --- a/component-model/src/design/interfaces.md +++ b/component-model/src/design/interfaces.md @@ -1,10 +1,52 @@ # Interfaces -An **interface** describes a single-focus, composable contract, through which components can interact with each other and with hosts. Interfaces describe the types and functions used to carry out that interaction. For example: +Interfaces are based on the idea of [design by contract][wp-contract]. +In software design, a _contract_ is a specification +of how a unit of code should behave. -* A "receive HTTP requests" interface might have only a single "handle request" function, but contain types representing incoming requests, outgoing responses, HTTP methods and headers, and so on. -* A "wall clock" interface might have two functions, one to get the current time and one to get the granularity of the timer. It would also include a type to represent an instant in time. +Conceptually, an _interface_ describes a single-focus, +composable contract +through which components can interact with each other +and with hosts. +* _Single-focus_: By convention, an interface describes + types and functions that are related to each other + and collectively provide a relatively small unit of + functionality, + such as reading from the standard input stream + in a command-line environment. +* _Composable_: Interfaces can be imported and exported. + One component's interfaces can be built + on top of interfaces defined in a different component. + Interfaces enable typechecking so that interfaces can + be composed only when it makes sense to do so. + +Concretely, an interface is a collection of type definitions +and function declarations +that are used to carry out interactions between components. +For example: + +* A "receive HTTP requests" interface might declare + a single "handle request" function, + along with definitions of types representing + incoming requests, outgoing responses, + HTTP methods and headers, and other data structures. +* A "wall clock" interface might declare two functions, + one to get the current time + and one to get the granularity of the timer (whether time + is measured in seconds, milliseconds, nanoseconds, or another unit). + It would also define a type to represent an instant in time. + +As an example of composing interfaces together, +imagine defining a "timer" interface that declares two functions, +one to start a timer and one to query whether the timeout +has been exceeded. +This interface could be defined by importing the "wall clock" +interface. +The result is an interface that exports the timer functionality, +and imports anything imported by the "wall clock" interface. Interfaces are defined using [the WIT language](./wit.md). -> For a more formal definition of what an interface is, take a look at the [WIT specification](https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md). +[wp-contract]: https://en.wikipedia.org/wiki/Design_by_contract + +> For a more formal definition of an interface, take a look at the [WIT specification](https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md). diff --git a/component-model/src/design/packages.md b/component-model/src/design/packages.md index 295c96a0..a05bab4f 100644 --- a/component-model/src/design/packages.md +++ b/component-model/src/design/packages.md @@ -1,9 +1,18 @@ # WIT Packages -A **WIT package** is a set of one or more [WIT (Wasm Interface Type)](./wit.md) files containing a related set of interfaces and worlds. WIT is an IDL (interface definition language) for the Component Model. Packages provide a way for worlds and interfaces to refer to each other, and thus for an ecosystem of components to share common definitions. +A **WIT package** is a set of one or more [WIT (Wasm Interface Type)](./wit.md) files +that, taken together, contain a set of interfaces and worlds that are related to each other. +WIT is an IDL (interface definition language) for the component model. +Packages provide a way for worlds and interfaces to refer to each other, +and thus for an ecosystem of components to share common definitions. -A WIT package is not a [world](./worlds.md). It's a way of grouping related interfaces and worlds together for ease of discovery and reference, more like a namespace. +A WIT package is like a namespace for grouping related interfaces and worlds together +for ease of discovery and reference. +A package is not a [world](./worlds.md). -* The WebAssembly System Interface (WASI) defines a number of packages, including one named `wasi:clocks`. Our HTTP proxy world could import the `wall-clock` interface from the `wasi:clocks` package, rather than having to define a custom clock interface. +* The WebAssembly System Interface (WASI) defines a number of packages, + including one named `wasi:clocks`. + Our HTTP proxy world could import the `wall-clock` interface from the `wasi:clocks` package, + rather than having to define a custom clock interface. > For a more formal definition of what a WIT package is, take a look at the [WIT specification](https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md). diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md index af0a57b9..6b675efa 100644 --- a/component-model/src/design/why-component-model.md +++ b/component-model/src/design/why-component-model.md @@ -55,7 +55,9 @@ Kinds of definitions include: * And others; see [the Core Specification](https://webassembly.github.io/spec/core/syntax/modules.html) for the complete list. -Core modules can be run in the browser, +A compiled core module is sometimes called a "WebAssembly binary", +and usually corresponds to a single `.wasm` file. +These modules can be run in the browser, or via a separate runtime such as [Wasmtime](https://wasmtime.dev/) or [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime). diff --git a/component-model/src/design/worlds.md b/component-model/src/design/worlds.md index e708c68f..cf23f459 100644 --- a/component-model/src/design/worlds.md +++ b/component-model/src/design/worlds.md @@ -1,20 +1,90 @@ # WIT Worlds -A **WIT world** is a higher-level contract that describes a component's capabilities and needs. +A **WIT world** (or just "world") is a contract with a broader scope +than a single interface. +A world describes the functionality a component provides, +and the functionality it requires in order to work. -On one hand, a world describes the shape of a component - it says which interfaces the component exposes for other code to call (its exports), and which interfaces the component depends on (its imports). A world only defines the surface of a component, not the internal behaviour. If you're an application or library developer creating a component, you'll specify the world your component targets. This world describes the functionality your component exposes and declares the functionality your component depends on in order to be able to run. Your component may target a custom world definition you have created with a unique set of imports and exports tailored just for your use case, or it may target an existing world definition that someone else has already specified. +A world simultaneously describes a component, +and a hosting environment for other components. +This is because components can be composed: a component +can provide functionality that other components can depend on. -On the other hand though, a world defines a _hosting environment_ for components (i.e., an environment in which a component can be instantiated and its functionality can be invoked). An environment supports a world by providing implementations for all of the imports and by optionally invoking one or more of the exports. +On the one hand, a world describes how a component relates to other components: +it describes the functionality the component exposes +and declares the functionality it depends on in order to be able to run. +Functionality is exposed by defining interfaces to export, +and dependencies are declared by importing interfaces. +A world only defines the surface of a component, not its internal behaviour. -For example, WASI (the WebAssembly System Interface) defines a "command line" world which imports interfaces that command line programs typically expect to have available to them such as file I/O, random number generation, clocks and so on. This world has a single export for running the command line tool. Components targeting this world must provide an implementation for this single export, and they may optionally call any of the imports. On the other hand, environments supporting this world must provide implementations for all of the imports and may invoke the single export. +On the other hand, a world defines a hosting environment for components: +that is, an environment in which a component can be instantiated +and its functionality can be invoked. +* In WebAssembly, _instantiation_ means turning a static description of a module + into a dynamic structure in memory. + It's analogous to [loading](https://en.wikipedia.org/wiki/Loader_(computing)) + an executable file. -A world is composed of interfaces, but each interface is _directional_ - it indicates whether the interface is available for outside code to call (an "export"), or whether outside code must fulfill the interface for the component to call (an "import"). These interfaces strictly bound the component. A component cannot interact with anything outside itself except by having its exports called, or by it calling its imports. This provides very strong sandboxing; for example, if a component does not have an import for a secret store, then it _cannot_ access that secret store, even if the store is running in the same process. +A hosting environment supports a world by providing implementations +for all of the imports +and by optionally invoking one or more of the exports. +If you're an application or library developer creating a component, +you'll specify the world your component targets. +Your component may target a custom world definition you have created +with a unique set of imports and exports tailored just for your use case, +or it may target an existing world definition that someone else has already specified. +In either case, the world specifies all the external functionality your component needs. +Targeting a world is analogous to relying on a particular version of a standard library, +except that components give you the ability to precisely specify +exactly what functions your code depends on. -For a component to run, its imports must be fulfilled, by a host or by other components. Connecting up some or all of a component's imports to other components' matching exports is called _composition_. +For example, WASI (the WebAssembly System Interface) defines a "command line" world +that imports interfaces that command-line programs typically expect to have available to them: +for example, file input/output, random number generation, and clocks. +This world has a single export for running the command-line tool. +Components targeting this world must provide an implementation for this single export, +and they may optionally call any of the imports. +For example, a component that prints out a summary of the sizes of files +in a particular directory (like the Unix `du` command) +could target the "command line" world, and would depend on +the file input/output interfaces imported by the world. +A hosting environment that supports this world +must provide implementations for all of the imports +and may invoke the single export. +Running your example disk usage component +would mean invoking it in a hosting environment +that supports the "command line" world. + +A world is a collection of interfaces, where each interface is _directional_. +Each interface is explicitly labeled as either an export or an import. +Exported interfaces are available for outside code to call, +whereas imported interfaces must be fulfilled by outside code. +These interfaces define a strict boundary for a component. +The only ways a component can interact with anything outside itself +are by having its exports called, +or by calling its imports. +This boundary provides very strong sandboxing: +for example, if a component does not have an import for a secret store, +then it _cannot_ access that secret store, +even if the store is running in the same process. + +For a component to run, its imports must be fulfilled, by a host or by other components. +Connecting up some or all of a component's imports to other components' matching exports is called _composition_. + +A world is defined in a WIT file; a single WIT files can contain multiple worlds. ## Example Worlds -* A (trivial) "HTTP proxy" world would export a "handle HTTP requests" interface, and import a "send HTTP requests" interface. A host, or another component, would call the exported "handle" interface, passing an HTTP request; the component would forward it on via the imported "send" interface. To be a _useful_ proxy, the component may also need to import interfaces such as I/O and clock time - without those imports the component could not perform, for example, on-disk caching. -* A "regex parser" world would export a "parse regex" function, and would import nothing. This declares not only that the component implementing this world can parse regular expressions, but also that it calls no other APIs. A user of such a parser could know, without looking at the implementation, that is does not access the file system, or send the user's regexes to a network service. +* A (trivial) "HTTP proxy" world would export a "handle HTTP requests" interface +and import a "send HTTP requests" interface. +A host, or another component, would call the exported "handle" interface, passing an HTTP request; +the component would forward it on via the imported "send" interface. +To be a _useful_ proxy, the component may also need to import interfaces such as I/O and clock time: +without those imports the component could not perform on-disk caching or other needed features. +* A "regex parser" world would export a "parse regex" function, and would import nothing. +This declares not only that the component implementing this world can parse regular expressions, +but also that it calls no other APIs. +A user of such a parser could know, without looking at the implementation, +that it does not access the file system or send the user's regexes to a network service. > For a more formal definition of what a WIT world is, take a look at the [WIT world specification](https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md#wit-worlds). From 556c5ecd9b189fb31c6017128349824c21e5faad Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 14:25:02 -0700 Subject: [PATCH 02/29] Update component-model/src/design/component-model-concepts.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/component-model-concepts.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index 216c7e0c..89e584f2 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -1,8 +1,8 @@ ## Component Model Concepts The WebAssembly Component Model extends core WebAssembly -by introducing higher-level types -and interface-driven development. +by adding consistent representation of higher-level types +and enabling interface-driven development, amongst other benefits. The Component Model makes core WebAssembly composable: components that provide functionality and those that use them can be composed together into *one* resulting component. From da8a8d057715b40d32f9a6918835e2927a18104e Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 14:26:40 -0700 Subject: [PATCH 03/29] Update component-model/src/design/component-model-concepts.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/component-model-concepts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index 89e584f2..a8a7435f 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -14,7 +14,7 @@ For the rationale behind the component model, see [the previous section](./why-c A [WebAssembly Component](./components.md) is a core module extended with higher-level types and interfaces. WebAssembly components are *nestable*: -they may contain one or more core modules and/or sub-components composed together. +they may contain zero or more core modules and/or sub-components composed together. For example, a component implementing a simple calculator might be written by composing together a component that parses strings to floating-point numbers with a component that does the main arithmetic. From 8908c9851218bf7eb39b59bdaff433fbdaec1844 Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 14:26:52 -0700 Subject: [PATCH 04/29] Update component-model/src/design/component-model-concepts.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/component-model-concepts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index a8a7435f..d16faa72 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -22,7 +22,7 @@ with a component that does the main arithmetic. ### WebAssembly Interface Types (WIT) [WebAssembly Interface Types (WIT)][wit] is the [IDL (Interface Definition Language)][wiki-idl] -used to formally define functionality for WebAssembly modules. +used to formally define functionality for WebAssembly components. WIT gives WebAssembly components the ability to express type signatures in a language-agnostic way, so any component binary can be both checked and executed. From 1075e5744b8f7b99c8eedab93485cf9f47c6fc58 Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 14:27:47 -0700 Subject: [PATCH 05/29] Update component-model/src/design/component-model-concepts.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/component-model-concepts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index d16faa72..ca4264ed 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -25,7 +25,7 @@ with a component that does the main arithmetic. used to formally define functionality for WebAssembly components. WIT gives WebAssembly components the ability to express type signatures in a language-agnostic way, -so any component binary can be both checked and executed. +so any component binary can be checked, composed and executed. ### Interfaces From bb836a8ac5a5a69df7bf114ab3e57a8f48ca41ce Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 14:28:53 -0700 Subject: [PATCH 06/29] Update component-model/src/design/component-model-concepts.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/component-model-concepts.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index ca4264ed..578a2786 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -35,8 +35,7 @@ Typically, a single interface describes a specific, focused bit of functionality. For example, in [wasi-cli][wasi-cli-stdio], three separate interfaces are used to implement `stdin`, `stdout`, and `stderr` -(the three input and output streams typically available -in a command-line environment.) +(streams typically available in command-line-like environments) ### Worlds From 0944d7b12f8a2899b5d20dbb9722ca1770a727bc Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 14:29:57 -0700 Subject: [PATCH 07/29] Update component-model/src/design/component-model-concepts.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/component-model-concepts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index 578a2786..4584b865 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -39,7 +39,7 @@ three separate interfaces are used to implement `stdin`, `stdout`, and `stderr` ### Worlds -A [_world_](./worlds.md) is a collection of interfaces +A [_world_](./worlds.md) is a collection of interfaces and types that expresses what features a component offers and what features it depends on. For example, wasi-cli includes the [`stdio` world][wasi-cli-stdio], From 2fc2e5dc5f631baa4ca81521dd293620559237fc Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 15:33:44 -0700 Subject: [PATCH 08/29] Update component-model/src/design/component-model-concepts.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/component-model-concepts.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index 4584b865..09cc9c94 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -58,8 +58,8 @@ must implement those three interfaces. ### Platforms -In the context of WebAssembly, the _host_ is the browser or stand-alone runtime -that runs WebAssembly modules. +In the context of WebAssembly, a _host_ refers to a WebAssembly runtime +capable of executing WebAssembly binaries. The _guest_ is the WebAssembly module that is executed by the host. (These terms come from virtualization, where a guest is a software-based virtual machine that runs on physical hardware, From 8ab3dc10e5df41d7dde6e5e94fe525af924ddf90 Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 15:34:44 -0700 Subject: [PATCH 09/29] Update component-model/src/design/component-model-concepts.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/component-model-concepts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index 09cc9c94..3e407ac1 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -60,7 +60,7 @@ must implement those three interfaces. In the context of WebAssembly, a _host_ refers to a WebAssembly runtime capable of executing WebAssembly binaries. -The _guest_ is the WebAssembly module that is executed by the host. +A _guest_ refers to the WebAssembly binary that is executed by the host. (These terms come from virtualization, where a guest is a software-based virtual machine that runs on physical hardware, which is the "host") From 935c9bb8b80d5d550f2f1dccf954bb49fc029272 Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 15:35:13 -0700 Subject: [PATCH 10/29] Update component-model/src/design/component-model-concepts.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/component-model-concepts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index 3e407ac1..e81f6e5a 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -61,7 +61,7 @@ must implement those three interfaces. In the context of WebAssembly, a _host_ refers to a WebAssembly runtime capable of executing WebAssembly binaries. A _guest_ refers to the WebAssembly binary that is executed by the host. -(These terms come from virtualization, where a guest is +(These terms borrow from their analogs in [virtualization](https://en.wikipedia.org/wiki/Virtualization), where a guest is a software-based virtual machine that runs on physical hardware, which is the "host") From 09a8449270d6afa18eaf206770a2c0aff8315278 Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 15:37:51 -0700 Subject: [PATCH 11/29] Update component-model/src/design/component-model-concepts.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/component-model-concepts.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index e81f6e5a..8e765c98 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -73,9 +73,9 @@ of host functionality for WebAssembly guests. The WebAssembly System Interface ([WASI][wasi]) defines in WIT a family of interfaces for common system-level functions. -WASI standardizes the functionality provided by platforms, -so that component writers can rely on functionality -that is guaranteed to be available on any conformant platform. +WASI defines a platform for component writers that mimics +existing programs that developers are familiar with (ex. `wasi-cli`, `wasi-http`), +standardizing the functionality components depend on. WASI defines common collections of functionality such as the command line ([`wasi:cli`][wasi-cli]) From 4b5026b5b900a6e6e07554dc3c4156ee8f2598c9 Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 15:39:33 -0700 Subject: [PATCH 12/29] Integrate review feedback in component-model-concepts.md --- .../src/design/component-model-concepts.md | 38 +++++++++++-------- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index 8e765c98..69d92cf8 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -12,7 +12,11 @@ For the rationale behind the component model, see [the previous section](./why-c ### Components -A [WebAssembly Component](./components.md) is a core module extended with higher-level types and interfaces. +A [WebAssembly Component](./components.md) is a binary that +conforms to the [Canonical ABI](../advanced/canonical-abi.md); +often a WebAssembly core module extended with the features +of the Component Model +(higher-level types, interfaces). WebAssembly components are *nestable*: they may contain zero or more core modules and/or sub-components composed together. For example, a component implementing a simple calculator might be written @@ -27,7 +31,7 @@ WIT gives WebAssembly components the ability to express type signatures in a language-agnostic way, so any component binary can be checked, composed and executed. -### Interfaces +#### Interfaces An [_interface_](./interfaces.md) is a collection of type definitions and function declarations (function names accompanied by type signatures). @@ -42,24 +46,26 @@ three separate interfaces are used to implement `stdin`, `stdout`, and `stderr` A [_world_](./worlds.md) is a collection of interfaces and types that expresses what features a component offers and what features it depends on. -For example, wasi-cli includes the [`stdio` world][wasi-cli-stdio], -which collects together three separate interfaces -that represent the `stdin`, `stdout`, and `stderr` streams. -Any component implementing the `stdio` world -must implement those three interfaces. +For example, wasi-cli includes the [`command` world][wasi-cli-command], +which depends on interfaces +that represent the `stdin`, `stdout`, and `stderr` streams, +among other things. +A component implementing the `command` world +must be invoked in an environment that implements those interfaces. ### Packages A [_package_](./packages.md) is a set of WIT files containing a related set of interfaces and worlds. - For example, the wasi-cli package includes - the `stdio` world and the `environment` world, among others, - with each defined in its own WIT file. + For example, the [wasi-http](https://github.com/WebAssembly/wasi-http/blob/main/wit/proxy.wit) package includes +an `imports` world encapsulating the interfaces that an HTTP proxy depends on, +and a `proxy` world that depends on `imports`. ### Platforms In the context of WebAssembly, a _host_ refers to a WebAssembly runtime capable of executing WebAssembly binaries. +The runtime can be inside a browser or can stand alone. A _guest_ refers to the WebAssembly binary that is executed by the host. (These terms borrow from their analogs in [virtualization](https://en.wikipedia.org/wiki/Virtualization), where a guest is a software-based virtual machine that runs on physical hardware, @@ -68,19 +74,18 @@ which is the "host") The Component Model introduces the idea of a _platform_ to core WebAssembly—enabling the structured, standardized use of host functionality for WebAssembly guests. +Components may import functionality that is provided +by the platform on which they are executed. -## WASI +### WASI The WebAssembly System Interface ([WASI][wasi]) defines in WIT a family of interfaces for common system-level functions. WASI defines a platform for component writers that mimics -existing programs that developers are familiar with (ex. `wasi-cli`, `wasi-http`), +existing programs that developers are familiar with +(for example, `wasi-cli` or `wasi-http`), standardizing the functionality components depend on. -WASI defines common collections of functionality -such as the command line ([`wasi:cli`][wasi-cli]) -or an HTTP server ([`wasi:http`][wasi-http]). - > [!NOTE] > The Component Model is stewarded by the [Bytecode Alliance](https://bytecodealliance.org/) and designed [in the open][cm-repo]. > @@ -95,6 +100,7 @@ or an HTTP server ([`wasi:http`][wasi-http]). [wasi]: https://wasi.dev/ [wasi-cli]: https://github.com/WebAssembly/wasi-cli/ [wasi-cli-stdio]: https://github.com/WebAssembly/wasi-cli/blob/main/wit/stdio.wit +[wasi-cli-command]: https://github.com/WebAssembly/wasi-cli/blob/main/wit/command.wit [wasi-http]: https://github.com/WebAssembly/wasi-http [!NOTE]: # From a3470bfeeb7c682b7d38b84005c7f36b5c15ae53 Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 15:44:55 -0700 Subject: [PATCH 13/29] Update component-model/src/design/components.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/component-model/src/design/components.md b/component-model/src/design/components.md index bed86e6c..35587997 100644 --- a/component-model/src/design/components.md +++ b/component-model/src/design/components.md @@ -1,6 +1,6 @@ # Components -Conceptually, a component is a self-describing unit of code +Conceptually, a component is a self-describing WebAssembly binary that interacts only through interfaces instead of shared memory. Let's break down what each of these terms means: From 5a164a7149bc2e85966f04903c96a084cf0a86d4 Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 15:45:23 -0700 Subject: [PATCH 14/29] Update component-model/src/design/components.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/component-model/src/design/components.md b/component-model/src/design/components.md index 35587997..8d7b93ca 100644 --- a/component-model/src/design/components.md +++ b/component-model/src/design/components.md @@ -27,7 +27,7 @@ Let's break down what each of these terms means: Logically, a component is a structure that may contain core modules and/or other components. The component encodes the interfaces of these contained -modules and sub-components using [WIT](./wit.md). +modules and sub-components using [WebAssembly Interface Types (WIT)](./wit.md). The on-disk representation of a component is a specially-formatted WebAssembly file. From 92d2be00d9bd634e7d36016b5fd429bcc8da5fdf Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 15:47:09 -0700 Subject: [PATCH 15/29] Update component-model/src/design/components.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/component-model/src/design/components.md b/component-model/src/design/components.md index 8d7b93ca..afe5ca91 100644 --- a/component-model/src/design/components.md +++ b/component-model/src/design/components.md @@ -34,7 +34,7 @@ is a specially-formatted WebAssembly file. Internally, this file could include representations of one or many traditional ("core") WebAssembly modules and sub-components, -`composed` via their imports and exports. +composed together via their imports and exports. Two modules or components can be composed if the imports of one are satisfied by the exports of another. Composition can be repeated arbitarily, composing a From 820635a19f5ac3f19d7d6f15350e8333ac5b1e94 Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 15:48:43 -0700 Subject: [PATCH 16/29] Update component-model/src/design/interfaces.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/interfaces.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/component-model/src/design/interfaces.md b/component-model/src/design/interfaces.md index e3341b0c..a0d552ba 100644 --- a/component-model/src/design/interfaces.md +++ b/component-model/src/design/interfaces.md @@ -4,8 +4,7 @@ Interfaces are based on the idea of [design by contract][wp-contract]. In software design, a _contract_ is a specification of how a unit of code should behave. -Conceptually, an _interface_ describes a single-focus, -composable contract +Conceptually, an _interface_ describes a single-focus, composable contract through which components can interact with each other and with hosts. * _Single-focus_: By convention, an interface describes From 7613d4769433ff1946c87d38c19f5a9cf6446a99 Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 15:50:52 -0700 Subject: [PATCH 17/29] Update component-model/src/design/interfaces.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/interfaces.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/component-model/src/design/interfaces.md b/component-model/src/design/interfaces.md index a0d552ba..d162d7c9 100644 --- a/component-model/src/design/interfaces.md +++ b/component-model/src/design/interfaces.md @@ -21,7 +21,7 @@ and with hosts. Concretely, an interface is a collection of type definitions and function declarations -that are used to carry out interactions between components. +that are used to enable interactions between components and hosts. For example: * A "receive HTTP requests" interface might declare From f59ab1496a7af83c774ebf28992d81b7cb15b71a Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 15:55:21 -0700 Subject: [PATCH 18/29] Integrate review feedback into Components section --- component-model/src/design/components.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/component-model/src/design/components.md b/component-model/src/design/components.md index afe5ca91..c4a800b6 100644 --- a/component-model/src/design/components.md +++ b/component-model/src/design/components.md @@ -29,11 +29,13 @@ that may contain core modules and/or other components. The component encodes the interfaces of these contained modules and sub-components using [WebAssembly Interface Types (WIT)](./wit.md). +> For a more formal definition of a component, +> take a look at the [Component Model specification](https://github.com/WebAssembly/component-model). + The on-disk representation of a component -is a specially-formatted WebAssembly file. +is [a specially-formatted WebAssembly binary](../advanced/canonical-abi.md). Internally, this file could include representations -of one or many traditional ("core") WebAssembly modules -and sub-components, +of one or many traditional ("core") WebAssembly modules and sub-components, composed together via their imports and exports. Two modules or components can be composed if the imports of one are satisfied by the exports of another. @@ -48,5 +50,11 @@ to describe all the imports and exports of the component. The world only describes the types of imported and exported functions; the component internally defines the code to implement the world. -> For a more formal definition of a component, -> take a look at the [Component Model specification](https://github.com/WebAssembly/component-model). +## Composition + +Two modules or components can be composed if the +imports of one are satisfied by the exports of another. +Composition can be repeated arbitarily, composing a +single component out of many interlocking modules and components. +[Interfaces](./interfaces.md) enable checking that +a particular composition makes sense. From 715d2f9ff8be228b1068a5e54a1012b89b87dbee Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 15:59:54 -0700 Subject: [PATCH 19/29] Integrate review feedback into Interfaces section --- component-model/src/design/interfaces.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/component-model/src/design/interfaces.md b/component-model/src/design/interfaces.md index d162d7c9..afee0701 100644 --- a/component-model/src/design/interfaces.md +++ b/component-model/src/design/interfaces.md @@ -4,6 +4,8 @@ Interfaces are based on the idea of [design by contract][wp-contract]. In software design, a _contract_ is a specification of how a unit of code should behave. +Concretely, an interface is a collection of type definitions +and function declarations. Conceptually, an _interface_ describes a single-focus, composable contract through which components can interact with each other and with hosts. @@ -29,11 +31,15 @@ For example: along with definitions of types representing incoming requests, outgoing responses, HTTP methods and headers, and other data structures. + This might look like the `incoming-handler` interface + in [wasi-http][wasi-http-handler] * A "wall clock" interface might declare two functions, one to get the current time and one to get the granularity of the timer (whether time is measured in seconds, milliseconds, nanoseconds, or another unit). It would also define a type to represent an instant in time. + This might look like the `wall-clock` interface + in [wasi-clocks][wasi-clocks-wall-clock]. As an example of composing interfaces together, imagine defining a "timer" interface that declares two functions, @@ -47,5 +53,7 @@ and imports anything imported by the "wall clock" interface. Interfaces are defined using [the WIT language](./wit.md). [wp-contract]: https://en.wikipedia.org/wiki/Design_by_contract +[wasi-http-handler]: https://github.com/WebAssembly/wasi-http/blob/main/wit/handler.wit +[wasi-clocks-wall-clock]: https://github.com/WebAssembly/wasi-clocks/blob/main/wit/wall-clock.wit > For a more formal definition of an interface, take a look at the [WIT specification](https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md). From e8c222ef7e9e8c6ca2148d929234a2a103c12968 Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 16:04:29 -0700 Subject: [PATCH 20/29] Integrate review feedback into Packages section --- component-model/src/design/packages.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/component-model/src/design/packages.md b/component-model/src/design/packages.md index a05bab4f..f66056f8 100644 --- a/component-model/src/design/packages.md +++ b/component-model/src/design/packages.md @@ -1,18 +1,23 @@ # WIT Packages -A **WIT package** is a set of one or more [WIT (Wasm Interface Type)](./wit.md) files +A **WIT package** is a set of one or more [WebAssembly Interface Type](./wit.md) (WIT) files that, taken together, contain a set of interfaces and worlds that are related to each other. -WIT is an IDL (interface definition language) for the component model. +WIT is an [interface definition language][wp-idl] (IDL) for the component model. Packages provide a way for worlds and interfaces to refer to each other, and thus for an ecosystem of components to share common definitions. -A WIT package is like a namespace for grouping related interfaces and worlds together +A WIT package groups related interfaces and worlds together for ease of discovery and reference. -A package is not a [world](./worlds.md). +A package is not a [world](./worlds.md): a package maps to one or more files +and contains worlds. +A world is a bundle of imported and exported types and interfaces. * The WebAssembly System Interface (WASI) defines a number of packages, including one named `wasi:clocks`. - Our HTTP proxy world could import the `wall-clock` interface from the `wasi:clocks` package, + Our HTTP proxy world could import the `wasi:clocks/wall-clock` interface + (read as "the `wall-clock` interface from the `wasi:clocks` package"), rather than having to define a custom clock interface. > For a more formal definition of what a WIT package is, take a look at the [WIT specification](https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md). + +[wp-idl]: https://en.wikipedia.org/wiki/Interface_description_language From 68f5da5ee439f0735e02b6b97a322d1a310c9195 Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 16:06:08 -0700 Subject: [PATCH 21/29] Update component-model/src/design/worlds.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/worlds.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/component-model/src/design/worlds.md b/component-model/src/design/worlds.md index cf23f459..4f46c590 100644 --- a/component-model/src/design/worlds.md +++ b/component-model/src/design/worlds.md @@ -5,7 +5,7 @@ than a single interface. A world describes the functionality a component provides, and the functionality it requires in order to work. -A world simultaneously describes a component, +A world can be used to describe a component, and a hosting environment for other components. This is because components can be composed: a component can provide functionality that other components can depend on. From 93385ea72433af75a947bf7e16bc81ba5e9e38bf Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 16:07:05 -0700 Subject: [PATCH 22/29] Update component-model/src/design/worlds.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/worlds.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/component-model/src/design/worlds.md b/component-model/src/design/worlds.md index 4f46c590..6c7dfaa6 100644 --- a/component-model/src/design/worlds.md +++ b/component-model/src/design/worlds.md @@ -6,7 +6,8 @@ A world describes the functionality a component provides, and the functionality it requires in order to work. A world can be used to describe a component, -and a hosting environment for other components. +and a hosting environment for other components, +depending on which imports and exports are specified. This is because components can be composed: a component can provide functionality that other components can depend on. From 43bcee521b27b9b3e96de90d0d70c98013d6327c Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 16:07:33 -0700 Subject: [PATCH 23/29] Update component-model/src/design/worlds.md Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> --- component-model/src/design/worlds.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/component-model/src/design/worlds.md b/component-model/src/design/worlds.md index 6c7dfaa6..906c0233 100644 --- a/component-model/src/design/worlds.md +++ b/component-model/src/design/worlds.md @@ -8,7 +8,9 @@ and the functionality it requires in order to work. A world can be used to describe a component, and a hosting environment for other components, depending on which imports and exports are specified. -This is because components can be composed: a component +Worlds can represent either a component or host environment because components can +be composed: a component can provide functionality required by another component, just +like a host environment can. can provide functionality that other components can depend on. On the one hand, a world describes how a component relates to other components: From dbb9569b515845ba745e2d4be7d4d1dbea41cb3a Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Thu, 24 Jul 2025 16:11:56 -0700 Subject: [PATCH 24/29] Integrate review feedback into Worlds section --- component-model/src/design/worlds.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/component-model/src/design/worlds.md b/component-model/src/design/worlds.md index 906c0233..dcb3b5bc 100644 --- a/component-model/src/design/worlds.md +++ b/component-model/src/design/worlds.md @@ -6,12 +6,14 @@ A world describes the functionality a component provides, and the functionality it requires in order to work. A world can be used to describe a component, -and a hosting environment for other components, +and a hosting environment for other components, depending on which imports and exports are specified. -Worlds can represent either a component or host environment because components can -be composed: a component can provide functionality required by another component, just -like a host environment can. -can provide functionality that other components can depend on. +Worlds can represent either a component or host environment +because components can be composed: +a component can provide functionality required by another component, +just like a host environment can. + +## Fulfilling worlds with components versus hosts On the one hand, a world describes how a component relates to other components: it describes the functionality the component exposes @@ -41,6 +43,8 @@ Targeting a world is analogous to relying on a particular version of a standard except that components give you the ability to precisely specify exactly what functions your code depends on. +## Example: the `wasi:cli` world + For example, WASI (the WebAssembly System Interface) defines a "command line" world that imports interfaces that command-line programs typically expect to have available to them: for example, file input/output, random number generation, and clocks. @@ -58,6 +62,8 @@ Running your example disk usage component would mean invoking it in a hosting environment that supports the "command line" world. +## Worlds and interfaces + A world is a collection of interfaces, where each interface is _directional_. Each interface is explicitly labeled as either an export or an import. Exported interfaces are available for outside code to call, @@ -76,7 +82,7 @@ Connecting up some or all of a component's imports to other components' matching A world is defined in a WIT file; a single WIT files can contain multiple worlds. -## Example Worlds +## Example worlds * A (trivial) "HTTP proxy" world would export a "handle HTTP requests" interface and import a "send HTTP requests" interface. From 9e9bde9ee2e65993889b2e295a1bbfc03d015a6b Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Mon, 28 Jul 2025 12:26:46 -0700 Subject: [PATCH 25/29] Integrate suggestions from code review --- component-model/src/design/component-model-concepts.md | 8 ++++---- component-model/src/design/interfaces.md | 5 ++--- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index 69d92cf8..8fff3c9f 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -1,9 +1,9 @@ ## Component Model Concepts -The WebAssembly Component Model extends core WebAssembly -by adding consistent representation of higher-level types -and enabling interface-driven development, amongst other benefits. -The Component Model makes core WebAssembly composable: +The WebAssembly Component Model extends core WebAssembly in several ways: +* It adds consistent representation of higher-level types +* It enables interface-driven development +* It makes core WebAssembly composable: components that provide functionality and those that use them can be composed together into *one* resulting component. diff --git a/component-model/src/design/interfaces.md b/component-model/src/design/interfaces.md index afee0701..42991729 100644 --- a/component-model/src/design/interfaces.md +++ b/component-model/src/design/interfaces.md @@ -21,9 +21,8 @@ and with hosts. Interfaces enable typechecking so that interfaces can be composed only when it makes sense to do so. -Concretely, an interface is a collection of type definitions -and function declarations -that are used to enable interactions between components and hosts. +The types and functions in an interface +are used to enable interactions between components and hosts. For example: * A "receive HTTP requests" interface might declare From 3e7fdbc82593e5582630ef423c1a63d72e4b824f Mon Sep 17 00:00:00 2001 From: Tim Chevalier Date: Mon, 28 Jul 2025 12:38:57 -0700 Subject: [PATCH 26/29] Rewrite initial para --- component-model/src/design/component-model-concepts.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index 8fff3c9f..543398b1 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -1,9 +1,10 @@ ## Component Model Concepts -The WebAssembly Component Model extends core WebAssembly in several ways: -* It adds consistent representation of higher-level types -* It enables interface-driven development -* It makes core WebAssembly composable: +The WebAssembly Component Model extends core WebAssembly in several ways. +The Component Model: +* Adds consistent representation of higher-level types +* Enables interface-driven development +* Makes core WebAssembly composable: components that provide functionality and those that use them can be composed together into *one* resulting component. From f559345d5362a7e2341b1b8e28d2547c643f9544 Mon Sep 17 00:00:00 2001 From: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> Date: Wed, 30 Jul 2025 22:52:21 +0900 Subject: [PATCH 27/29] refactor: acronym link --- component-model/src/design/component-model-concepts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index 543398b1..a3347aca 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -26,7 +26,7 @@ with a component that does the main arithmetic. ### WebAssembly Interface Types (WIT) -[WebAssembly Interface Types (WIT)][wit] is the [IDL (Interface Definition Language)][wiki-idl] +[WebAssembly Interface Types (WIT)][wit] is the [Interface Definition Language (IDL)][wiki-idl] used to formally define functionality for WebAssembly components. WIT gives WebAssembly components the ability to express type signatures in a language-agnostic way, From aab24d42c6d76795732ad1d8756e6b8a1fa94792 Mon Sep 17 00:00:00 2001 From: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> Date: Wed, 30 Jul 2025 22:58:08 +0900 Subject: [PATCH 28/29] chore: add some spacing --- component-model/src/design/component-model-concepts.md | 1 + 1 file changed, 1 insertion(+) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index a3347aca..275aca54 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -38,6 +38,7 @@ An [_interface_](./interfaces.md) is a collection of type definitions and function declarations (function names accompanied by type signatures). Typically, a single interface describes a specific, focused bit of functionality. + For example, in [wasi-cli][wasi-cli-stdio], three separate interfaces are used to implement `stdin`, `stdout`, and `stderr` (streams typically available in command-line-like environments) From fef7ff02b8717bd2f5f600eac652d53b9ba52fe7 Mon Sep 17 00:00:00 2001 From: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com> Date: Wed, 30 Jul 2025 22:58:46 +0900 Subject: [PATCH 29/29] chore: add more spacing --- component-model/src/design/component-model-concepts.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/component-model/src/design/component-model-concepts.md b/component-model/src/design/component-model-concepts.md index 275aca54..76d738fa 100644 --- a/component-model/src/design/component-model-concepts.md +++ b/component-model/src/design/component-model-concepts.md @@ -48,6 +48,7 @@ three separate interfaces are used to implement `stdin`, `stdout`, and `stderr` A [_world_](./worlds.md) is a collection of interfaces and types that expresses what features a component offers and what features it depends on. + For example, wasi-cli includes the [`command` world][wasi-cli-command], which depends on interfaces that represent the `stdin`, `stdout`, and `stderr` streams, @@ -58,8 +59,9 @@ must be invoked in an environment that implements those interfaces. ### Packages A [_package_](./packages.md) is a set of WIT files - containing a related set of interfaces and worlds. - For example, the [wasi-http](https://github.com/WebAssembly/wasi-http/blob/main/wit/proxy.wit) package includes +containing a related set of interfaces and worlds. + +For example, the [wasi-http](https://github.com/WebAssembly/wasi-http/blob/main/wit/proxy.wit) package includes an `imports` world encapsulating the interfaces that an HTTP proxy depends on, and a `proxy` world that depends on `imports`.