LGTM1. Following along with Mozilla's long-standing implementation SGTM, and obviates the need for a TAG review. It would be ideal to file an official standards position issue with WebKit, however, to make sure they understand that we do intend to ship this and can incorporate that information into their planning and positioning.
There were questions in that earlier thread about web platform tests. Looks like they landed in https://github.com/web-platform-tests/wpt/pull/37910/files, which is great. Thanks! -mike On Fri, May 26, 2023 at 11:32 AM Nidhi Jaju <nidhij...@chromium.org> wrote: > Contact emailsnidhij...@chromium.org > > ExplainerNone > > Specificationhttps://fetch.spec.whatwg.org/#http-network-fetch > > Summary > > Makes Response.body be a readable byte stream instead of a "default" > readable stream. This enables it to be used with bring-your-own-buffer > (BYOB) readers, reducing garbage collection overhead and copies. > > As mentioned in the Activation section below, we plan to ship the > ReadableStreamTeeCloneForBranch2 feature first, and then the FetchBYOB > feature later. > Blink componentBlink>Network>FetchAPI > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork%3EFetchAPI> > > TAG reviewNone > > TAG review statusNot applicable > > Risks > > > Interoperability and Compatibility > > Low risk because streams and fetch have already been standardized for a > long time. Other browsers have implemented other parts of the standard, and > Firefox has already shipped this behavior for many months and others will > most likely also adapt this feature as well soon. > > > *Gecko*: Shipped/Shipping ( > https://github.com/whatwg/fetch/issues/267#issuecomment-1350303670) > Already shipped in Firefox in 2022. > > *WebKit*: Positive (https://github.com/whatwg/fetch/pull/1593) @annevk > from Apple approved the PR to update the spec with relevant changes and > expressed interest as an implementer on behalf of Apple. > > *Web developers*: No signals > > *Other signals*: Deno is also interested in, and somewhat shipped, this > behavior (https://github.com/denoland/deno/issues/17386). > > Activation > > Currently, to clone a body, we tee the body's stream, but teeing always > returns two "default" streams, where the chunks are not cloned for both > streams. Making Response.body into a byte stream, will mean that cloning it > will result in cloning the chunks for the second stream, which is different > behavior. In order to mitigate activation risks, we are splitting this > change into two releases. One where the default teeing behavior will also > start to clone for the second stream behind the > "ReadableStreamTeeCloneForBranch2" feature flag, and then make > Response.body a readable byte stream behind the "FetchBYOB" feature flag. > > > 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? > > > > Debuggability > > No special support needed. > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, Chrome OS, Android, and Android WebView)?Yes > > This feature will be purely implemented in Blink and so cross-platform > support is automatic. > > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ?Yes > > Flag nameReadableStreamTeeCloneForBranch2 and FetchBYOB > > Requires code in //chrome?False > > Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1243329 > > Estimated milestones > Shipping on desktop 116 > Shipping on Android 116 > Shipping on WebView 116 > > Anticipated spec changes > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > None. The spec change for BYOB support for Fetch was already landed at > https://github.com/whatwg/fetch/pull/1593. > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5192003450568704 > > Links to previous Intent discussionsIntent to prototype: > https://groups.google.com/a/chromium.org/g/blink-dev/c/Iyt6Ca9PiJQ/m/s_D7A0YwCgAJ > > -- > 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/CAMZNYANt%2BwCoAYOfh1Bj7EJrdTz3jkd%3D%3DAyeBv9f8P2Ccu1wkg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANt%2BwCoAYOfh1Bj7EJrdTz3jkd%3D%3DAyeBv9f8P2Ccu1wkg%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/CAKXHy%3Df8HaN%3DXGBO2Sobvud2YyMD%2BQ_UUqhxJ2AFBDUeCNtrjg%40mail.gmail.com.
