diff options
| author | Mircea Trofin <mtrofin@google.com> | 2015-10-21 19:51:51 -0700 |
|---|---|---|
| committer | Mircea Trofin <mtrofin@google.com> | 2015-10-21 19:51:51 -0700 |
| commit | 7347fc654d230a4887bf24db194ce57bab04b286 (patch) | |
| tree | 6559c0844f09b9ae6464f3401eeaab0f8ee8082e /FeatureTest.md | |
| parent | 22eb1e44362fd0aa5be0e1adbf1081dbd4919a10 (diff) | |
| download | nanowasm-design-7347fc654d230a4887bf24db194ce57bab04b286.tar.gz | |
Incorporated feedback.
- link to PostMVP.md
- replaced pronouns with giving the user a name in each scenario, and then using the appropriate pronoun. This makes cross-referencing scenarios easier, too.
Diffstat (limited to 'FeatureTest.md')
| -rw-r--r-- | FeatureTest.md | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/FeatureTest.md b/FeatureTest.md index f00a682..b826380 100644 --- a/FeatureTest.md +++ b/FeatureTest.md @@ -1,16 +1,16 @@ # Motivating Scenarios -1. In MVP + 1 (the version of the WebAssembly after MVP), [`i32.min_s`](FutureFeatures.md#additional-integer-operations) is introduced. A developer updates her toolkit and targets the new features. The compiler leverages `i32.min_s` when compiling a module the developer wrote. The developer's WebAssembly module works correctly both on execution environments at MVP, as well as those updated on MVP + 1. +1. In MVP + 1 (the version of the WebAssembly [after MVP](PostMVP.md)), [`i32.min_s`](FutureFeatures.md#additional-integer-operations) is introduced. Mary, a WebAssembly developer, updates her toolkit and targets the new features. The compiler leverages `i32.min_s` when compiling a module the developer wrote. Mary's WebAssembly module works correctly both on execution environments at MVP, as well as those updated on MVP + 1. -2. In MVP + 1, module authors may now use [Threading](PostMVP.md#threads) APIs in the browser. A developer wants to leverage multithreading in her module. - * In one variant of the scenario, the developer does not want to pay the engineering cost of developing and supporting a threaded and non-threaded version of her code. She opts to not support MVP targets, and only support MVP + 1 targets. End-users (browser users) get some message indicating they need MVP support. - * In another variant, the developer explicitly authors both MVP-only and MVP + 1 (with threads) code. +2. In MVP + 1, module authors may now use [Threading](PostMVP.md#threads) APIs in the browser. Bob is such a developer, and he wants to leverage multithreading in his module. + * In one variant of the scenario, Bob does not want to pay the engineering cost of developing and supporting a threaded and non-threaded version of her code. He opts to not support MVP targets, and only support MVP + 1 targets. End-users (browser users) get some message indicating they need MVP support. + * In another variant, Bob explicitly authors both MVP-only and MVP + 1 (with threads) code. -3. [SIMD](PostMVP.md#fixed-width-simd) support is not universally equivalent on all targets. While polyfill variants of SIMD APIs are available, a developer prefers writing dedicated SIMD and non-SIMD versions of her compresion algorithm, because the non-SIMD version performs better in environments without SIMD support, when compared to the SIMD polyfill. She packages her compression code for reuse by third parties. +3. [SIMD](PostMVP.md#fixed-width-simd) support is not universally equivalent on all targets. While polyfill variants of SIMD APIs are available, Jane prefers writing dedicated SIMD and non-SIMD versions of her compresion algorithm, because the non-SIMD version performs better in environments without SIMD support, when compared to the SIMD polyfill. She packages her compression code for reuse by third parties. -4. A developer is assembling together an application reusing modules developed in the scenarios above. Their development environment is able to quickly and correctly identify the platform dependencies (e.g. threading, SIMD) and communicate to the developer the implications these dependencies have on the end-application. Some APIs exposed from the threading-aware module are only pertinent to environments supporting threading. As a consequence, our developer needs to write specialized code when threads are/are not supported. +4. Chris is assembling together an application reusing modules developed in the scenarios above. His development environment is able to quickly and correctly identify the platform dependencies (e.g. threading, SIMD) and communicate back to him the implications these dependencies have on the end-application. Some APIs exposed from the threading-aware module are only pertinent to environments supporting threading. As a consequence, Chris needs to write specialized code when threads are/are not supported. (Note: we should understand ghis scenario for both forms of WebAssembly reuse currently imagined - dynamic linking and static imports.) -5. A module (for example the compression one), or the application described in the scenarios above, is deployed on a restrictive execution environment where a process may not change memory page access protection flags (certain gaming consoles, to investigate server side deployment scenarios). The module is compiled by the WebAssembly environment, enabling the configuration most specific to the target (i.e. with/without Threads, SIMD, etc). +5. Jane's compression algorithm module is deployed on a restrictive execution environment, as part of an application. In this environment, a process may not change memory page access protection flags (e.g. certain gaming consoles, to investigate server side deployment scenarios). Jane's module is compiled by the WebAssembly environment, enabling the configuration most specific to the target (i.e. with/without Threads, SIMD, etc). * A variant of this scenario where the environment is additionally separating storage into system-visible and application-visible, the latter not being able to contain machine-executable code (certain phones, to investigate if gaming consoles or server side have a similar sandboxing mechanism). # Feature Test |
