Like Rick, I'm also unsure why this isn't an I2S for the new design. Are y'all really unsure that the latest iteration has open issues that need resolution before shipping? Is there an minimum-viable subset you can ship now while extensions are debated behind another OT?
Best, Alex On Mon, Jun 24, 2024, 1:47 PM 'Francis McCabe' via blink-dev < blink-dev@chromium.org> wrote: > I am 'ok' with a shorter extension. I asked for 6 months because I foresee > a reasonable risk of needing more than 3 milestones. > > I am not 'ok' with shipping without the imprimatur of progress in the > standardization. We recently did ship a phase 3 standard -- exceptions -- > that turned out to be a mistake. It is likely going to be many years before > that can be fully unwound. > > To be clear: I do not anticipate any issues with the standard; but then, > no-one does. > > Francis > On Monday, June 24, 2024 at 12:47:23 PM UTC-7 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? >> >> Thanks, >> Rick >> >> On Mon, Jun 24, 2024 at 1:31 PM Francis McCabe <f...@chromium.org> wrote: >> >>> Contact emailsf...@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+...@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/46b78c6b-ae44-49ab-919c-3bd2194314f1n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/46b78c6b-ae44-49ab-919c-3bd2194314f1n%40chromium.org?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/CAA44PQhEkW5a9UK%2BdBj6SfMaQr%2B48jrmjX24V%2B19UVQu3UjZfg%40mail.gmail.com.
