You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/interfaces.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -35,18 +35,18 @@ WASI P1 APIs were defined with WITX Interface Description Language (IDL), which
35
35
36
36
## Proposals for the standard
37
37
38
-
All WASI APIs are **proposals** for standardization by the WASI Subgroup. The API proposals in WASI 0.1 and 0.2 met implementation and portability criteria for inclusion at the time of those releases. A proposal advances through the following stages as defined in the [WebAssembly W3C process](https://github.com/WebAssembly/meetings/blob/main/process/phases.md):
38
+
All WASI APIs are **proposals** for standardization by the WASI Subgroup. The API proposals in WASI 0.1 and 0.2 met implementation and portability criteria for inclusion at the time of those releases. A proposal advances through the following stages as defined in the [WASI Subgroup's Phase Process](https://github.com/WebAssembly/WASI/blob/main/Contributing.md#the-phase-process):
39
39
40
40
***Phase 0 - Pre-proposal**: The pre-proposal phase serves as a way to share ideas. At this phase, the WASI subgroup has not yet decided that the pre-proposal is in scope for WASI, and there may be overlap between pre-proposals.
41
41
***Phase 1 - Feature proposal**: In this phase, the proposal is added to the proposal list and a new fork of the spec repo is created.
42
-
***Phase 2 - Proposed spec text available**: During this phase, one or more implementations prototype the feature and a test suite is added.
42
+
***Phase 2 - Feature description available**: During this phase, one or more implementations prototype the feature and a test suite is added.
43
43
***Phase 3 - Implementation phase**: At this phase, project champions create releases following the conventions of semantic versioning (semver).
44
44
***Phase 4 - Standardize the feature:** At this point, the feature is fully handed off to the Working Group, where edge cases are considered and only minor changes occur.
45
45
***Phase 5 - The feature is standardized**: Once the Working Group reaches consensus that the feature is complete, editors perform final editorial tweaks and merge the feature into the main branch of the primary spec repo.
46
46
47
47
Proposals are first made to the **WASI Subgroup** of the [WebAssembly Community Group](https://www.w3.org/community/webassembly/). (See the [WASI Subgroup's meeting schedule](https://github.com/WebAssembly/meetings/tree/main/wasi).)
48
48
49
-
All active WASI API proposals can be found on the [WASI GitHub repository](https://github.com/WebAssembly/WASI/blob/main/Proposals.md), along with the [process for making a proposal](https://github.com/WebAssembly/WASI/blob/main/Contributing.md#the-phase-process).
49
+
All active WASI API proposals can be found on the [WASI GitHub repository](https://github.com/WebAssembly/WASI/blob/main/Proposals.md). See the [Contributing to WASI page](https://github.com/WebAssembly/WASI/blob/main/Contributing.md) for information about submitting a new proposal.
50
50
51
51
## Active Proposals
52
52
@@ -149,4 +149,4 @@ Some APIs may require backwards-incompatible changes over time. In these cases,
Copy file name to clipboardExpand all lines: docs/introduction.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,8 +3,8 @@ title: "Introduction"
3
3
slug: /
4
4
sidebar_position: 1
5
5
---
6
-
7
-
The **WebAssembly System Interface (WASI)** is a group of standard API specifications for software compiled to the **[W3C WebAssembly (Wasm) standard](https://www.w3.org/TR/wasm-core-2/)**. WASI is designed to provide a secure standard interface for applications that can be compiled to Wasm from any language, and that may run anywhere—from browsers to clouds to embedded devices.
6
+
7
+
The **WebAssembly System Interface (WASI)** is a group of standards-track API specifications for software compiled to the **[W3C WebAssembly (Wasm) standard](https://www.w3.org/TR/wasm-core-2/)**. WASI is designed to provide a secure standard interface for applications that can be compiled to Wasm from any language, and that may run anywhere—from browsers to clouds to embedded devices.
8
8
9
9
By standardizing APIs for WebAssembly, WASI provides a way to compose software written in different languages—without costly and clunky interface systems like HTTP-based microservices. We believe that every project with a plugin model should be using WASI, and that WASI is ideally suited for projects with SDKs for multiple languages, e.g. client libraries.
10
10
@@ -20,7 +20,7 @@ WASI and Wasm are tools for any type of software developer: whether you're writi
20
20
21
21
## How to get started
22
22
23
-
There are many different runtimes that support WASI including [Wasmtime](https://wasmtime.dev/), [WAMR](https://bytecodealliance.github.io/wamr.dev/), [WasmEdge](https://wasmedge.org/), [wazero](https://wazero.io/), [Wasmer](https://wasmer.io/), [wasmi](https://github.com/wasmi-labs/wasmi), and [wasm3](https://github.com/wasm3/wasm3). Many of these runtimes have different areas of focus (i.e., IoT, embedded devices, and edge for WAMR, or server-side and non-web embeddings with components for Wasmtime). The introductory documentation for each is a great place to start.
23
+
There are many different runtimes that support WASI including [Wasmtime](https://wasmtime.dev/), [WAMR](https://bytecodealliance.github.io/wamr.dev/), [WasmEdge](https://wasmedge.org/), [wazero](https://wazero.io/), [Wasmer](https://wasmer.io/), [wasmi](https://github.com/wasmi-labs/wasmi), [wasm3](https://github.com/wasm3/wasm3), and [jco](https://github.com/bytecodealliance/jco). Many of these runtimes have different areas of focus (i.e., IoT, embedded devices, and edge for WAMR, server-side and non-web embeddings with components for Wasmtime, and running in JS environments and browsers for Jco). The introductory documentation for each is a great place to start.
24
24
25
25
WASI can be implemented by both core Wasm modules and applications built according to the **Component Model**, a specification for Wasm applications that are interoperable and composable. You can learn more about components in the Bytecode Alliance's **[WebAssembly Component Model](https://component-model.bytecodealliance.org/)** documentation.
0 commit comments