|
| 1 | +# WASI High-Level Goals |
| 2 | + |
| 3 | +(In the spirit of [WebAssembly's High-Level Goals](https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md).) |
| 4 | + |
| 5 | +1. Define a portable, modular, runtime-independent, and WebAssembly-native API |
| 6 | + to serve as a system interface which can be used by WebAssembly code to |
| 7 | + interact with the outside world, that preserves the essential sandboxed |
| 8 | + nature of WebAssembly through a [Capability-based] API design. |
| 9 | +2. Specify and implement incrementally: |
| 10 | + * Start with a Minimum Viable Product (MVP) for the standard, covering |
| 11 | + basic API versioning, feature detection, and namespacing. |
| 12 | + * Then add additional features, prioritized by feedback and experience. |
| 13 | +3. Supplement API designs with documentation and tests, and, when feasible, |
| 14 | + reference implementations which can be shared between wasm engines. |
| 15 | +4. Make a great platform: |
| 16 | + * Work with WebAssembly tool and library authors to help them provide |
| 17 | + WASI support for their users. |
| 18 | + * When being WebAssembly-native means the platform isn't directly |
| 19 | + compatible with existing applications written for other platforms, |
| 20 | + build tools and libraries to provide compatibility. |
| 21 | + * Allow the overall API to evolve over time; to make changes to API |
| 22 | + modules that have been standardized, build implementations of them |
| 23 | + using libraries on top of new API modules to provide compatibility. |
| 24 | + |
| 25 | +[Capability-based]: https://en.wikipedia.org/wiki/Capability-based_security |
0 commit comments