Add a HighLevelGoals.md document. #18
Conversation
|
It would be nice to mention some post-MVP features like threads, because people are really curious about them |
|
My suggestion here is that we should start a roadmap document covering threads and other desirable features, rather than put everything in High-Level Goals. Does that sound reasonable? |
|
Absolutely |
…mespacing. Per discussion in the WASI-05-02.md meeting change the MVP description to scope it to just versioning, feature detection, and namespacing.
|
Following up on the discussion from the last meeting, I've now updated the HighLevelGoals.md document to reflect an MVP that just focused on versioning, feature detection, and namespacing. |
|
Is "namespacing" meant to cover both the modularity (dividing standard APIs into modules) and extensibility (embedder implements extra non-standard modules or APIs) use cases? Is it worth calling those out separately? |
|
@dschuff, it is meant to cover both of those, yes. Additionally, it should be possible to provide modules/APIs indistinguishable from (standard on non-standard) builtin ones through other WASI modules. That enables seamless polyfilling, plus maintenance of backwards-compatibility through shims for versioned APIs. |
|
Landing, as discussed in today's meeting. Looking forward to following up with more documentation on namespacing and capability-based security! |
This PR adds a High-Level Goals document, in the spirit of the core WebAssembly High-Level Goals.
Of particular note, this document lays out a rough outline for an MVP milestone, which roughly contains the feature set of what's currently called WASI Core, though that's just a starting point. That said, the Subgroup can also continue to work on features outside the MVP scope concurrently.
Comments, questions, and suggestions welcome!