diff options
| author | JF Bastien <github@jfbastien.com> | 2015-10-27 06:09:43 -1000 |
|---|---|---|
| committer | JF Bastien <github@jfbastien.com> | 2015-10-27 06:09:43 -1000 |
| commit | bcd71874f255f3bf041f2dcd1a7eb882eca6de4a (patch) | |
| tree | 5c7b1664fe025fe17fd29470ae0c5115682b70c6 | |
| parent | 0bbef77d5789a081f2b67ede92ac4612c6a7c07a (diff) | |
| parent | eab56c5d3cf70882cc7bbffeff80c7aa7fa89784 (diff) | |
| download | nanowasm-design-bcd71874f255f3bf041f2dcd1a7eb882eca6de4a.tar.gz | |
Merge pull request #418 from mtrofin/patch-2
Capture of scenarios motivating feature testing.
| -rw-r--r-- | FeatureTest.md | 2 | ||||
| -rw-r--r-- | Rationale.md | 17 |
2 files changed, 19 insertions, 0 deletions
diff --git a/FeatureTest.md b/FeatureTest.md index 22bd780..a7a3aec 100644 --- a/FeatureTest.md +++ b/FeatureTest.md @@ -1,3 +1,5 @@ +See [rationale](Rationale.md#feature-testing---motivating-scenarios) for motivating scenarios. + # Feature Test The [MVP](MVP.md) allows an application to query which post-MVP features are diff --git a/Rationale.md b/Rationale.md index 1a0a1c3..7920ebd 100644 --- a/Rationale.md +++ b/Rationale.md @@ -240,3 +240,20 @@ architectures there may be a need to revisit some of the decisions: * When different languages have different expectations then it's unfortunate if WebAssembly measurably penalizes one's performance by enforcing determinism which that language doesn't care about, but which another language may want. + + +## Motivating Scenarios for Feature Testing +1. [Post-MVP](PostMVP.md), [`i32.min_s`](FutureFeatures.md#additional-integer-operations) is introduced. A WebAssembly developer updates their toolkit so that the compiler may leverage `i32.min_s`. The developer's WebAssembly module works correctly both on execution environments at MVP, as well as those supporting `i32.min_s`. + * A variant of this, where a few more new opcodes are available, the compiler is updated to be able to leverage all of them, but not all execution targets support all of them. The developer wants to reach as many of their customers as possible, while at the same time providing them with the best experience possible. The developer has to balance the cost of the test matrix resulting from the combinations of possible feature configurations. + +2. Post-MVP, module authors may now use [Threading](PostMVP.md#threads) APIs in the browser. A developer wants to leverage multithreading in their module. + * In one variant of the scenario, our developer does not want to pay the engineering cost of developing and supporting a threaded and non-threaded version of their code. They opt not to support MVP targets, and only support post-MVP targets. End-users (browser users) get some message indicating they need MVP support. + * In another variant, our developer explicitly authors both MVP-only and post-MVP (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 their compression algorithm, because the non-SIMD version performs better in environments without SIMD support, when compared to the SIMD polyfill. They package their compression code for reuse by third parties. + +4. An application author is assembling together an application by reusing modules such as those developed in the scenarios above. The application author's development environment is able to quickly and correctly identify the platform dependencies (e.g. threading, SIMD) and communicate back to the application author 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, the application author needs to write specialized code when threads are/are not supported. +(Note: we should understand this scenario for both forms of WebAssembly reuse currently imagined: dynamic linking and static imports.) + +5. The compression algorithm described in scenario 3 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). The compression 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). |
