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
* Add a definition for Preview 2.
Add a document defining the criteria for including proposals in Preview
2, as well as defining when Preview 2 is considered launched.
And, update the top-level README.md to point to this new document and to
reflect the updated Preview 2 plan.
* Rename "phase 4 acceptance criteria" to "portability criteria".
* Update README.md
* Update README.md
Copy file name to clipboardExpand all lines: README.md
+25-12Lines changed: 25 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,21 +4,23 @@
4
4
5
5

6
6
7
-
The WebAssembly System Interface is not a monolithic standard system interface,
8
-
but is instead a modular collection of standardized APIs. None of the APIs are
9
-
required to be implemented to have a compliant runtime. Instead, host
10
-
environments can choose which APIs make sense for their use cases.
7
+
The WebAssembly System Interface (WASI) is a set of APIs for WASI being
8
+
developed for eventual standardization by the WASI Subgroup, which is a
9
+
subgroup of the WebAssembly Community Group.
11
10
12
-
---
13
-
## Important Note: WASI is in transition
11
+
WASI started with launching what is now called [Preview 1], an API using
12
+
the witx IDL, and it is now widely used. Its major incluences are POSIX and
13
+
CloudABI.
14
14
15
-
WASI is transitioning away from the `witx` format and its early experimental ABI. We are transitioning to Interface Types using the `wit` format and the canonical ABI.
15
+
[WASI Preview 2] is now in development, which is a modular collection of
16
+
APIs defined with the [Wit IDL], and it incorporates many of the lessons
17
+
learned from Preview 1, including adding support for a wider range of
18
+
source languages, modularity, a more expressive type system,
19
+
virtualizability, and more.
16
20
17
-
All new API proposals should use the new format and the new repo structure that is shown in the [proposal template](https://github.com/WebAssembly/wasi-proposal-template).
18
-
19
-
See the [Wit in WASI](docs/WitInWasi.md) document for more information about using Wit for WASI proposals.
If you would like to create a new proposal, get started with our
34
36
[Contributing guide](Contributing.md).
35
37
38
+
All new API proposals should use the new format and the new repo structure that is shown in the [proposal template](https://github.com/WebAssembly/wasi-proposal-template).
39
+
40
+
See the [Wit in WASI](docs/WitInWasi.md) document for more information about using Wit for WASI proposals.
41
+
36
42
## WASI High Level Goals
37
43
38
44
(In the spirit of [WebAssembly's High-Level Goals](https://github.com/WebAssembly/design/blob/main/HighLevelGoals.md).)
@@ -129,3 +135,10 @@ API in WASI, so we don't need to exclude APIs just because some host
129
135
environments can't implement them. We prefer APIs which can run across
130
136
a wide variety of engines when feasible, but we'll ultimately decide
131
137
whether something is "portable enough" on an API-by-API basis.
138
+
139
+
### Modularity
140
+
141
+
WASI will include many interfaces that are not appropriate for every host
142
+
environment, so WASI uses the component model's worlds mechanism to allow
143
+
specific sets of APIs to be described which meet the needs of different
0 commit comments