From 22eb1e44362fd0aa5be0e1adbf1081dbd4919a10 Mon Sep 17 00:00:00 2001 From: Mircea Trofin Date: Wed, 21 Oct 2015 09:27:40 -0700 Subject: Separate scenarios motivating feature testing Moved a few of the already described scenarios, trying to isolate the motivating problem from possible solutions. Added a development time scenario and one for restrictive target environment. --- FeatureTest.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/FeatureTest.md b/FeatureTest.md index 0010b1e..f00a682 100644 --- a/FeatureTest.md +++ b/FeatureTest.md @@ -1,3 +1,18 @@ +# 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. + +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. + +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. + +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. +(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). + * 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 The [MVP](MVP.md) allows an application to query which post-MVP features are -- cgit v1.2.3 From 7347fc654d230a4887bf24db194ce57bab04b286 Mon Sep 17 00:00:00 2001 From: Mircea Trofin Date: Wed, 21 Oct 2015 19:51:51 -0700 Subject: 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. --- FeatureTest.md | 14 +++++++------- 1 file 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 -- cgit v1.2.3 From 4d692a0f06f70b0a425339a4799599097ac67d3f Mon Sep 17 00:00:00 2001 From: Mircea Trofin Date: Thu, 22 Oct 2015 22:48:42 -0700 Subject: Back to pronouns. --- FeatureTest.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/FeatureTest.md b/FeatureTest.md index b826380..53d099f 100644 --- a/FeatureTest.md +++ b/FeatureTest.md @@ -1,13 +1,13 @@ # Motivating Scenarios -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. +1. In MVP + 1 (the version of the WebAssembly [after MVP](PostMVP.md)), [`i32.min_s`](FutureFeatures.md#additional-integer-operations) is introduced. A WebAssembly developer updates their 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. -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. +2. In MVP + 1, 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 MVP + 1 targets. End-users (browser users) get some message indicating they need MVP support. + * In another variant, our developer 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, 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. +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 compresion 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. 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. +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 ghis scenario for both forms of WebAssembly reuse currently imagined - dynamic linking and static imports.) 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). -- cgit v1.2.3 From 639a7219b4274944ab82de73ade2297a00742954 Mon Sep 17 00:00:00 2001 From: Mircea Trofin Date: Mon, 26 Oct 2015 18:25:29 -0700 Subject: Moved Feature testing motivating scenarios Moved Feature testing motivating scenarios to Rationale.md --- Rationale.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/Rationale.md b/Rationale.md index 87bac8b..7c2f136 100644 --- a/Rationale.md +++ b/Rationale.md @@ -240,3 +240,19 @@ 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. + + +## Feature Testing - Motivating Scenarios +1. [PostMVP](PostMVP.md)), [`i32.min_s`](FutureFeatures.md#additional-integer-operations) is introduced. A WebAssembly developer updates their 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 able to target PostMVP features. + +2. PostMVP, 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 MVP + 1 targets. End-users (browser users) get some message indicating they need MVP support. + * In another variant, our developer 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 their compresion 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). 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). -- cgit v1.2.3 From 36f6256cfc61db8d0cbdbd4e325239dd8e391527 Mon Sep 17 00:00:00 2001 From: Mircea Trofin Date: Mon, 26 Oct 2015 18:26:02 -0700 Subject: Fixed small typo --- Rationale.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Rationale.md b/Rationale.md index 7c2f136..b684d13 100644 --- a/Rationale.md +++ b/Rationale.md @@ -243,7 +243,7 @@ architectures there may be a need to revisit some of the decisions: ## Feature Testing - Motivating Scenarios -1. [PostMVP](PostMVP.md)), [`i32.min_s`](FutureFeatures.md#additional-integer-operations) is introduced. A WebAssembly developer updates their 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 able to target PostMVP features. +1. [PostMVP](PostMVP.md), [`i32.min_s`](FutureFeatures.md#additional-integer-operations) is introduced. A WebAssembly developer updates their 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 able to target PostMVP features. 2. PostMVP, 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 MVP + 1 targets. End-users (browser users) get some message indicating they need MVP support. -- cgit v1.2.3 From 631a2c0befed980923d81ca7051343b3653f0de9 Mon Sep 17 00:00:00 2001 From: Mircea Trofin Date: Mon, 26 Oct 2015 18:28:44 -0700 Subject: Update FeatureTest.md --- FeatureTest.md | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/FeatureTest.md b/FeatureTest.md index 53d099f..5470b72 100644 --- a/FeatureTest.md +++ b/FeatureTest.md @@ -1,17 +1,4 @@ -# Motivating Scenarios -1. In MVP + 1 (the version of the WebAssembly [after MVP](PostMVP.md)), [`i32.min_s`](FutureFeatures.md#additional-integer-operations) is introduced. A WebAssembly developer updates their 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. - -2. In MVP + 1, 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 MVP + 1 targets. End-users (browser users) get some message indicating they need MVP support. - * In another variant, our developer 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 their compresion 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 ghis scenario for both forms of WebAssembly reuse currently imagined - dynamic linking and static imports.) - -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). +See [rationale](Rationale.md#feature-testing---motivating-scenarios) for motivating scenarios. # Feature Test -- cgit v1.2.3 From ee2413d8d7e5ad0a341c873ee2e0f17197329dce Mon Sep 17 00:00:00 2001 From: Mircea Trofin Date: Mon, 26 Oct 2015 19:32:24 -0700 Subject: Update Rationale.md --- Rationale.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Rationale.md b/Rationale.md index b684d13..91a6930 100644 --- a/Rationale.md +++ b/Rationale.md @@ -243,7 +243,8 @@ architectures there may be a need to revisit some of the decisions: ## Feature Testing - Motivating Scenarios -1. [PostMVP](PostMVP.md), [`i32.min_s`](FutureFeatures.md#additional-integer-operations) is introduced. A WebAssembly developer updates their 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 able to target PostMVP features. +1. [PostMVP](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. PostMVP, 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 MVP + 1 targets. End-users (browser users) get some message indicating they need MVP support. -- cgit v1.2.3 From b5be0bad9dbbb3affa48adcaac67c1035e2bb32c Mon Sep 17 00:00:00 2001 From: Mircea Trofin Date: Mon, 26 Oct 2015 22:32:50 -0700 Subject: Update Rationale.md --- Rationale.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Rationale.md b/Rationale.md index 91a6930..2da0212 100644 --- a/Rationale.md +++ b/Rationale.md @@ -242,18 +242,18 @@ architectures there may be a need to revisit some of the decisions: which that language doesn't care about, but which another language may want. -## Feature Testing - Motivating Scenarios -1. [PostMVP](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`. +## 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. PostMVP, 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 MVP + 1 targets. End-users (browser users) get some message indicating they need MVP support. - * In another variant, our developer explicitly authors both MVP-only and MVP + 1 (with threads) code. + * 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 compresion 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. +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.) +(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). Jane's module is compiled by the WebAssembly environment, enabling the configuration most specific to the target (i.e. with/without Threads, SIMD, etc). +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). -- cgit v1.2.3 From eab56c5d3cf70882cc7bbffeff80c7aa7fa89784 Mon Sep 17 00:00:00 2001 From: Mircea Trofin Date: Tue, 27 Oct 2015 09:01:09 -0700 Subject: Update Rationale.md --- Rationale.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Rationale.md b/Rationale.md index 2da0212..f19e98a 100644 --- a/Rationale.md +++ b/Rationale.md @@ -246,7 +246,7 @@ architectures there may be a need to revisit some of the decisions: 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. PostMVP, module authors may now use [Threading](PostMVP.md#threads) APIs in the browser. A developer wants to leverage multithreading in their module. +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. -- cgit v1.2.3