LGTM to extend experimentation until M130 inclusive On Thu, Jul 11, 2024 at 1:54 PM Emanuel Ziegler <ecmzieg...@chromium.org> wrote:
> Just to clarify: the current OT already runs until M127 inclusive, we are > asking for an extension to M130. > Ok, that wasn't clear from your intent, but I should have asked for clarifications on that front. Apologies! > > Also, there was significant progress on the spec since the last extension. > The proposal has moved from phase 2 to phase 3 since then including > fulfilling all the requirements for that transition. Only the *formal* > spec is lacking and will be completed in the upcoming months before > reaching phase 4. > The Blink process cares less about phase transitions (prior to phase 4, which we use to gauge consensus) and more about actual specifications. > > Thanks, > Emanuel > > > On Thu, Jul 11, 2024 at 1:06 PM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> LGTM to experiment until M127, inclusive. >> >> After some discussions amongst the API owners, I think there's no real >> mismatch. >> The Blink process does have more requirements for OT renewals than the >> WASM process does for stage 3 proposals, but that not necessarily a >> contradiction. >> Therefore I would have expected y'all to make progress on a spec >> regardless of the WASM process stage before asking for this renewal. >> At the same time, given that the requirements may have not been very >> clear, I don't want this to be a blocker here. >> But if another extension is needed, I'd expect to see some significant >> progress on both the spec and WPT-streaming front. >> >> On Wednesday, July 10, 2024 at 4:45:52 AM UTC+2 Domenic Denicola wrote: >> >> Thanks for clarifying the Wasm process. It sounds like there's some >> mismatch between its more lax requirements, and the requirements of the >> Blink process for shipping things in Chromium, and in particular the >> requirements for extending an experiment. >> >> It sounds like it would be easy to make progress on the WPTs requirement, >> but potentially not very useful for the community, if all the Wasm engines >> are using the existing JS API tests and not paying attention to WPTs until >> a later stage. And, it would be hard to make progress on the spec >> requirement. >> >> I'm inclined to approve the extension, as it's clear you all are making a >> good-faith effort to shape this feature in response to developer and >> implementer feedback and using the experiment framework as intended. >> However, since it contradicts the letter of the process, please give us a >> day or so to discuss amongst API owners and make sure others are OK with >> this kind of exception. And maybe, as Mike mentioned during the last >> extension >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/k7DQ3qYbn90/m/zVjoH0ixAQAJ>, >> we should codify some of these exceptions into the Blink process to avoid >> the clash in the future. >> >> On Wed, Jul 10, 2024 at 12:09 AM Emanuel Ziegler <ecmzieg...@chromium.org> >> wrote: >> >> Thanks for taking a look! The progress is in alignment with the Wasm spec >> process requirements. Please see my answers below where I provide more >> background. >> >> On Mon, Jul 8, 2024 at 6:04 AM Domenic Denicola <dome...@chromium.org> >> wrote: >> >> >> >> On Thu, Jul 4, 2024 at 2:50 AM Emanuel Ziegler <ecmzieg...@chromium.org> >> wrote: >> >> Dear API owners, >> >> We would like to request an extension of the origin trial for Wasm JS >> String Builtins >> <https://developer.chrome.com/origintrials/#/view_trial/2142587522721513473>. >> There were recent changes to the initialization of string constants >> (implicit imports) which improved startup time and binary size on local >> measurements. >> >> We would like to use the experiment to verify the viability of this >> change in the wild (effect on load and startup times) and upcoming changes >> to it (variable import namespace for greater flexibility). Sheets/J2Wasm >> already implemented the first part and wants to roll it out to users in the >> next weeks as part of the origin trial. >> >> The proposal is progressing well along the requested dimensions >> >> - Draft spec (early draft is ok, but must be spec-like and associated >> with the appropriate standardization venue, or WICG) >> - The proposal continues to be actively maintained and changed >> with plenty of community engagement. >> - Recent changes mostly affected string constants and their >> initialization. >> >> To me, the proposal document does not seem very "spec-like", but instead >> like an explainer. Is there a formal specification available? >> >> >> This is in accordance with common practice and in line with the Wasm >> proposal workflow. To quote from the official documentation >> <https://github.com/WebAssembly/meetings/blob/main/process/phases.md#3-implementation-phase-community--working-group> >> for >> phase 3: >> >> *"Updates on the actual spec document and reference interpreter are NOT >> yet required"* >> >> >> Instead they only happen during phase 3 in preparation for phase 4 (final >> stage). Until then, the overview/explainer document is the main source of >> truth to avoid double maintenance. Spec changes also often require the >> assistance of a Wasm spec expert and we want to keep the overhead for those >> low. The overhead of maintaining spec updates will hopefully improve in a >> year or two with the planned switch to SpecTec >> <https://github.com/Wasm-DSL/spectec/blob/main/spectec/README.md> which >> will make the spec more accessible to proposal champions and implementers. >> >> >> - TAG review (see exceptions >> <https://www.chromium.org/blink/guidelines/api-owners/process-exceptions/> >> ) >> - A TAG review has been requested >> <https://github.com/w3ctag/design-reviews/issues/940> and is >> scheduled for discussion. >> - bit.ly/blink-signals requests >> - Firefox/SpiderMonkey is actively working on their prototype and >> the champion behind this proposal. >> - Safari/JSC expressed openness to the proposal but no official >> confirmation yet. >> - Outreach for feedback from the spec community >> - The proposal (including string constant changes) was voted to >> phase 3 at the on-site Wasm CG meeting on June 5 with unanimous >> consent. >> - WPT tests >> - WPTs will likely be added based on the already existing JS API >> tests in the proposal repository >> >> <https://github.com/WebAssembly/js-string-builtins/tree/main/test/js-api/js-string> >> (see GitHub issue 33 on the proposal repository >> <https://github.com/WebAssembly/js-string-builtins/issues/33> on >> this question). >> >> Is there anything preventing you from upstreaming those tests to the web >> platform tests repository now? >> >> >> No, it wasn't a priority so far and is not required at all by the Wasm >> proposal process. Wasm engines don't use them as their primary correctness >> verification method. That's what Wasm spec tests are used for which have >> been added during phase 2 in alignment with the requirements. The use of >> WPTs for the browser community lies mostly in making support (or lack of >> it) transparent to web developers. As such, they are usually created once >> the feature is sufficiently stable to avoid extra maintenance and noise >> generated from updates and inconsistencies in between WPTs and Wasm spec >> tests. If you think there would be a benefit in merging them now, we can >> raise that with the proposal champion. >> >> >> More details on some of these items can be found in the updated >> experiment summary >> <https://docs.google.com/document/d/1zL9goDsawTQUFuuQ8ddI_pUcLY1_iFOsHaDZ374dnGw/edit> >> . >> >> Thank you, >> Emanuel >> >> >> Contact emailsecmzieg...@chromium.org, jkumme...@chromium.org, adamk@ >> chromium.org >> >> ExplainerNone >> >> Specificationhttps://github.com/WebAssembly/js-string- >> builtins/blob/main/proposals/js-string-builtins/Overview.md >> >> Summary >> >> This feature exposes common JS string operations for easy import into >> WebAssembly and optimizations thereof. This allows creating and >> manipulating JS strings from WebAssembly without native support within >> WebAssembly while still allowing for a similar performance as native string >> references. The mechanism works by exposing suitably strict versions of JS >> string operations in the WebAssembly JS API. These can be imported by >> modules using externref as a generic data type for storing the strings. The >> engine can identify that these imports can be represented by native graph >> operators without the need for calling into JS. This leads to a comparable >> peak performance as native string operations while allowing quick >> interoperability with JS since no copying at the boundary is required when >> calling into arbitrary JS functions that consume strings. >> >> >> Blink componentBlink>JavaScript>WebAssembly >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly> >> >> TAG reviewNone >> >> TAG review statusPending >> >> Chromium Trial NameWebAssemblyJSStringBuiltins >> >> Link to origin trial feedback summaryhttps://docs.google.com/document/d/ >> 1zL9goDsawTQUFuuQ8ddI_pUcLY1_iFOsHaDZ374dnGw/edit?usp=sharing >> >> Origin Trial documentation linkhttps://github.com/WebAssembly/js-string- >> builtins/blob/main/proposals/js-string-builtins/Overview.md >> >> Risks >> >> >> Interoperability and Compatibility >> >> None >> >> >> *Gecko*: Positive >> >> *WebKit*: No signal (https://github.com/WebKit/ >> standards-positions/issues/343) >> >> *Web developers*: No signals >> >> *Other signals*: >> >> 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? >> >> None >> >> >> Goals for experimentation >> >> >> >> Ongoing technical constraints >> >> None >> >> >> Debuggability >> >> None >> >> >> 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> >> ?No >> >> Flag name on chrome://flagsNone >> >> Finch feature nameNone >> >> Non-finch justificationNone >> >> Requires code in //chrome?False >> >> Estimated milestonesOrigin trial desktop first119Origin trial desktop >> last127Origin trial extension 1 end milestone127 >> >> Link to entry on the Chrome Platform Statushttps://chromestatus.com/ >> feature/6695587390423040?gate=5106659883220992 >> >> Links to previous Intent discussionsIntent to Experiment: https://groups. >> google.com/a/chromium.org/d/msgid/blink-dev/CAPAU7RyzxKa0Pj6q7B_jyfT%3DH% >> 2BSK264%3Dx8wn1ans%3D8UjHRhctQ%40mail.gmail.com >> Intent to Extend Experiment 1: https://groups.google.com/ >> a/chromium.org/d/msgid/blink-dev/CAPAU7RyYPNTcmt1uHe279qW46ff3S >> %3DZ-M%3DHZjKn%3DK%2Bgp_0DyZw%40mail.gmail.com?utm_medium= >> email&utm_source=footer >> Intent to Ship: https://groups.google.com/a/chromium.org/d/msgid/ >> blink-dev/CAPAU7RyYPNTcmt1uHe279qW46ff3S%3DZ-M%3DHZjKn%3DK%2Bgp_0DyZw% >> 40mail.gmail.com?utm_medium=email&utm_source=footer >> >> >> 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/CAPAU7RzGQhi3m4g_rTQt79LFFz6mdmT% >> 3D8YRVomA4UwAVcZQtrA%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPAU7RzGQhi3m4g_rTQt79LFFz6mdmT%3D8YRVomA4UwAVcZQtrA%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/CAOmohSKyq5K4h9uqmm2atJHrJeY4V%3Dxx5kW8MnRzq2ncM1BzgQ%40mail.gmail.com.
