The new API is actually a simplification of the 'old' API. It is not a question of base+extensions.
Note: the API design itself is gated by the WebAssembly stacks sub-group of the W3C community group. On Monday, June 24, 2024 at 2:44:56 PM UTC-7 sligh...@chromium.org wrote: > 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 < > blin...@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+...@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/fd927af1-b6c2-4832-9166-e0cd9f381552n%40chromium.org.
