On Mon, Jun 24, 2024 at 12:47 PM Rick Byers <rby...@chromium.org> wrote:
> Hi Francis, > We only do OT extensions for 3 milestones at a time > <https://www.chromium.org/blink/launching-features/#origin-trials:~:text=An%20initial%20origin%20trial%20or%20experiment%20for%20a%20feature%20may%20only%20run%20for%206%20milestones%20of%20Chromium.%20Each%20request%20to%20extend%20beyond%20that%20limit%20may%20only%20be%20for%203%20milestones%20at%20a%20time%2C%20and%20will%20not%20be%20approved%20unless%20substantial%20progress%20is%20demonstrated%20in%20all%20of%20these%20areas%3A>. > It sounds like there's been a meaningful change in the API that we need to > validate, so extending for another 3 to 131 sounds OK to me if you'd like > to do that, but that gets you only to October. > > Outside of JS / WASM features, we generally do not block on standards > maturity when shipping new APIs, since the chromium project has a policy of > limiting the cost on velocity that we're willing to pay in order to reach > standards consensus. What do you think the harm would be in shipping this > now and coming up with a versioning and/or breaking change strategy for any > changes which are deemed necessary after that? It sounds like you already > have customers relying on this feature (given the commitments you mention > around evolution of the API while in OT), so it's unclear whether shipping > and iterating would really be all that different in practice? > Apart from the API churn, the one requirement that we're missing for Phase 4 from the Wasm phases process <https://github.com/WebAssembly/meetings/blob/main/process/phases.md#4-standardize-the-feature-working-group> is the spec document. The Wasm CG has a high level of consensus for this feature, and while a reasonably complete overview exists, a full spec of the feature does seem like a reasonable requirement to block on (IIUC for JSPI the other requirements have already been met, or should be non-controversial). On the implementation front, there are a couple of upcoming changes to improve performance that introduce significant code churn. Having the OT extended even for a shorter duration would mean that we're able to validate performance for current JSPI users, and get better bake time for fuzzer coverage before shipping. Thanks, > Rick > > On Mon, Jun 24, 2024 at 1:31 PM Francis McCabe <f...@chromium.org> wrote: > >> Contact emails...@chromium.org >> >> Explainer >> https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md >> >> Specification >> https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md >> >> Design docs >> >> https://docs.google.com/document/d/16Us-pyte2-9DECJDfGm5tnUpfngJJOc8jbj54HMqE9Y/edit#heading=h.n1atlriavj6v >> >> Summary >> >> Stack Switching denotes a technology that allows programs to suspend and >> resume computation. This is an active area that is part of the WebAssembly >> standards track. See https://github.com/WebAssembly/stack-switching and >> https://github.com/WebAssembly/meetings/tree/main/stack. This particular >> feature refers to the integration between JavaScript Promises and stack >> switching. This is described in more detail in >> https://docs.google.com/document/d/16Us-pyte2-9DECJDfGm5tnUpfngJJOc8jbj54HMqE9Y/edit# >> >> >> Blink componentBlink>JavaScript>WebAssembly >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly> >> >> Search tagsstack switching >> <https://chromestatus.com/features#tags:stack%20switching>, Promise >> <https://chromestatus.com/features#tags:Promise>, JSPI >> <https://chromestatus.com/features#tags:JSPI> >> >> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/809 >> >> TAG review statusPending >> >> Chromium Trial NameWebAssemblyJSPromiseIntegration >> >> Origin Trial documentation link >> https://github.com/WebAssembly/js-promise-integration >> >> WebFeature UseCounter namekV8WasmJavaScriptPromiseIntegration >> >> Risks >> >> >> Interoperability and Compatibility >> >> This spec is backed by a standardization effort. We do not plan to ship >> the JSPI until it has been standardized by the W3C Wasm WG. However, post >> standardization, we will depend on all browsers implementing the standard. >> >> >> *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1850627) >> Mozilla have started their own imlementation >> >> *WebKit*: No signal >> >> *Web developers*: No signals >> >> *Other signals*: >> >> Activation >> >> Making use of JSPI requires some changes by WebAssembly-based developers >> (no impact on JavaScript developers). Depending on their toolchain usage a >> developer will need to modify their code. For Emscripten users, this is >> likely to be minimal as support for JSPI exists in Emscripten. >> >> >> Security >> >> 1. Control flow integrity. 2. Ensuring that JavaScript programs cannot >> suspend via JSPI. >> >> >> WebView application risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> >> >> Goals for experimentation >> >> >> >> Reason this experiment is being extended >> >> JSPI is part of a standards track effort. We are currently in 'stage 3' >> of a five stage process. The next stage (4) is when a specification is >> deemed final. There was a change in the API which we soft launched in M126 >> but we would like to formally switch to this new API in M129. (We had >> informed our users that we would be maintaining the old API through the end >> of the OT.) So, in summary there are two reasons for extending the origin >> trial: 1. We are not quite ready to move the spec to phase 4. This is for >> non-implementation reasons: we need to draft and review the specification >> text. 2. We would like to allow sufficient time for users to fully >> experiment with the new API. We anticipate being able to fully ship JSPI >> before the end of 2024, but also dont want to have to ask for yet another >> extension. >> >> >> Ongoing technical constraints >> >> None. >> >> >> Debuggability >> >> Developers can piggyback on existing DevTools support for Promises to >> help with debugging JSPI applications. In particular the existing >> mechanisms for constructing extended stack traces from so-called Promise >> chains will also include stack traces from JSPI applications. >> >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)?Yes >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?Partially >> >> Flag name on chrome://flags >> enable-experimental-webassembly-stack-switching >> >> Finch feature nameNone >> >> Non-finch justificationNone >> >> Requires code in //chrome?False >> >> Tracking bug >> https://bugs.chromium.org/p/v8/issues/detail?id=12191&q=owner%3Ame&can=2 >> >> Estimated milestones >> Origin trial desktop first 123 >> Origin trial desktop last 128 >> Origin trial extension 1 end milestone 134 >> DevTrial on desktop 109 >> OriginTrial Android last 128 >> OriginTrial Android first 123 >> OriginTrial webView last 128 >> OriginTrial webView first 123 >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5674874568704000?gate=5078038869180416 >> >> Links to previous Intent discussionsIntent to prototype: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAdKk6BGFseZ6pBO2qEW_xeovVw1_guVq26rcNM1nWY442Y5Ng%40mail.gmail.com >> Intent >> to Experiment: >> https://groups.google.com/a/chromium.org/g/blink-dev/c/Fu79zrp7MoE >> >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com/>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE65UWBDn_Vvj5uqqOVMABJWopy_ZfOz4P5ZZYiqCxa7HACxCA%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE65UWBDn_Vvj5uqqOVMABJWopy_ZfOz4P5ZZYiqCxa7HACxCA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9Kte1WKJVzPpMsnPMOj0vfBhqJ9XjiVi%3DNYyDm2TWy5g%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9Kte1WKJVzPpMsnPMOj0vfBhqJ9XjiVi%3DNYyDm2TWy5g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALi9WK-JJNTYSeNdSuai827Qg5%3D2vZo-emYP2z-5vJOfE%2B8Nng%40mail.gmail.com.
