Thanks Alex, We have a partner who need backpressure to avoid jank in their app. I've been waiting for them to comment, but it's taking a while.
Adam On Thu, 22 Feb 2024 at 01:53, Alex Russell <slightly...@chromium.org> wrote: > Hey Adam, > > Sorry for the slow follow up. Were there folks beyond the Deno ecosystem > that expressed interest and/or satisfaction with the design? We're need to > make a case in API OWNERS that there's enough developer interest to > surmount the lack of other vendor interest. Are you able to share more? > > Thanks, > > Alex > > On Friday, February 16, 2024 at 12:10:50 AM UTC-8 Adam Rice wrote: > >> Any reason the PR for the spec hasn't landed yet? >> >> >> We don't have interest from a second implementer yet. As far as I know, >> Deno doesn't count for this purpose. >> >> On Fri, 16 Feb 2024 at 03:50, Chris Harrelson <chris...@chromium.org> >> wrote: >> >>> Hi, >>> >>> Any reason the PR for the spec hasn't landed yet? >>> >>> On Thu, Feb 15, 2024 at 7:54 AM Mike Taylor <miketa...@chromium.org> >>> wrote: >>> >>>> Thank you - LGTM1 >>>> On 2/15/24 7:16 AM, Adam Rice wrote: >>>> >>>> Thanks Mike, >>>> >>>> I have requested the approvals. Sorry for the delay, I didn't >>>> understand the interface. >>>> >>>> Adam >>>> >>>> On Thu, 15 Feb 2024 at 01:39, Mike Taylor <miketa...@chromium.org> >>>> wrote: >>>> >>>>> Hi Adam, >>>>> >>>>> Would you mind requesting approvals in the chromestatus entry for the >>>>> various review gates? >>>>> On 2/8/24 1:30 AM, Adam Rice wrote: >>>>> >>>>> Unfortunately, no partners were ready when we did the OT, so there was >>>>> no feedback at all. However, we have subsequently received private >>>>> feedback >>>>> that the API works well. >>>>> >>>>> On Thu, 8 Feb 2024 at 04:23, Alex Russell <slightly...@chromium.org> >>>>> wrote: >>>>> >>>>>> Hey Adam, >>>>>> >>>>>> Glad to see this moving forward! Has there been a summary somewhere >>>>>> of the OT feedback? Also, we noted that the other reviews were marked as >>>>>> unstarted in chromestatus; we will likely hold off voting until those are >>>>>> in flight. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> On Tuesday, February 6, 2024 at 1:43:46 PM UTC-8 Adam Rice wrote: >>>>>> >>>>>>> Contact emails ri...@chromium.org >>>>>>> >>>>>>> Explainer >>>>>>> https://github.com/ricea/websocketstream-explainer/blob/master/README.md >>>>>>> >>>>>>> https://docs.google.com/document/d/1XuxEshh5VYBYm1qRVKordTamCOsR-uGQBCYFcHXP4L0/edit >>>>>>> >>>>>>> Specification https://github.com/whatwg/websockets/pull/48 >>>>>>> >>>>>>> Design docs >>>>>>> https://web.dev/websocketstream/ >>>>>>> >>>>>>> Summary >>>>>>> >>>>>>> The WebSocket API provides a JavaScript interface to the RFC6455 >>>>>>> WebSocket protocol. While it has served well, it is awkward from an >>>>>>> ergonomics perspective and is missing the important feature of >>>>>>> backpressure. The intent of the WebSocketStream API is to resolve these >>>>>>> deficiencies by integrating WHATWG Streams with the WebSocket API. >>>>>>> >>>>>>> >>>>>>> Blink component Blink>Network>WebSockets >>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork%3EWebSockets> >>>>>>> >>>>>>> Search tags WebSocket >>>>>>> <https://chromestatus.com/features#tags:WebSocket>, Streams >>>>>>> <https://chromestatus.com/features#tags:Streams>, ReadableStream >>>>>>> <https://chromestatus.com/features#tags:ReadableStream>, >>>>>>> WritableStream >>>>>>> <https://chromestatus.com/features#tags:WritableStream> >>>>>>> >>>>>>> TAG review https://github.com/w3ctag/design-reviews/issues/394 >>>>>>> >>>>>>> TAG review status Pending >>>>>>> >>>>>>> Chromium Trial Name WebSocketStream >>>>>>> >>>>>>> Link to origin trial feedback summary >>>>>>> https://github.com/ricea/websocketstream-explainer/issues >>>>>>> >>>>>>> Origin Trial documentation link >>>>>>> https://github.com/ricea/websocketstream-explainer/blob/master/README.md >>>>>>> >>>>>>> Risks >>>>>>> >>>>>>> >>>>>>> Interoperability and Compatibility >>>>>>> >>>>>>> The main risk is that it fails to become an interoperable part of >>>>>>> the web platform if other browsers do not implement it. >>>>>>> >>>>>>> >>>>>>> *Gecko*: No signal ( >>>>>>> https://github.com/mozilla/standards-positions/issues/970) >>>>>>> >>>>>>> *WebKit*: No signal ( >>>>>>> https://github.com/WebKit/standards-positions/issues/315) >>>>>>> >>>>>>> *Web developers*: No signals >>>>>>> >>>>>>> *Other signals*: The Deno runtime has implemented the API: >>>>>>> https://github.com/denoland/deno/issues/8831 >>>>>>> >>>>>>> Ergonomics >>>>>>> >>>>>>> A major focus of the new API is improving ergonomics over the >>>>>>> existing WebSocket API. >>>>>>> >>>>>>> >>>>>>> Activation >>>>>>> >>>>>>> Everything except for correct backpressure behaviour can be >>>>>>> polyfilled. Developers who are sensitive to backpressure may prefer to >>>>>>> feature-detect and fall back to application-level backpressure if the >>>>>>> feature is not available. >>>>>>> >>>>>>> >>>>>>> Security >>>>>>> >>>>>>> Security posture is the same as the existing WebSocket API. The >>>>>>> WebSocket mojo IPC layer was designed to support backpressure and didn't >>>>>>> need changes to support the new API. >>>>>>> >>>>>>> >>>>>>> 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? >>>>>>> >>>>>>> No specific risk. >>>>>>> >>>>>>> >>>>>>> Debuggability >>>>>>> >>>>>>> The necessary probes are included in the code so that existing >>>>>>> WebSocket debugging facilities work as-is. >>>>>>> >>>>>>> >>>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? Yes >>>>>>> >>>>>>> The feature is easy to support everywhere existing Blink WebSocket >>>>>>> support exists. Blink WebSockets are supported on every Blink platform. >>>>>>> >>>>>>> >>>>>>> Is this feature fully tested by web-platform-tests >>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>> ? Yes >>>>>>> >>>>>>> https://wpt.fyi/results/websockets/stream/tentative >>>>>>> >>>>>>> >>>>>>> Flag name on chrome://flags >>>>>>> about://flags/#enable-experimental-web-platform-features >>>>>>> >>>>>>> Finch feature name WebSocketStream >>>>>>> >>>>>>> Requires code in //chrome? False >>>>>>> >>>>>>> Tracking bug >>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=983030 >>>>>>> >>>>>>> Measurement Use counter: >>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/3018 >>>>>>> >>>>>>> Availability expectation The feature is relatively straightforward >>>>>>> to implement, so I would expect it to be available in other browsers >>>>>>> within >>>>>>> 12 months. >>>>>>> >>>>>>> Adoption expectation We have a partner who is ready to adopt this >>>>>>> as soon as it's available as the backpressure feature is critical for >>>>>>> them. >>>>>>> >>>>>>> Non-OSS dependencies >>>>>>> >>>>>>> Does the feature depend on any code or APIs outside the Chromium >>>>>>> open source repository and its open-source dependencies to function? >>>>>>> No. >>>>>>> >>>>>>> Sample links >>>>>>> >>>>>>> https://github.com/ricea/websocketstream-explainer/blob/master/README.md >>>>>>> >>>>>>> Estimated milestones >>>>>>> OriginTrial desktop last 80 >>>>>>> OriginTrial desktop first 78 >>>>>>> DevTrial on desktop 78 >>>>>>> DevTrial on Android 78 >>>>>>> >>>>>>> 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). >>>>>>> In future it is likely that an option to use byte streams will be >>>>>>> added, to allow efficient use of BYOB readers. The second parameter to >>>>>>> the >>>>>>> constructor is an option bag, permitting easy extensions. >>>>>>> https://github.com/ricea/websocketstream-explainer/issues/15 is >>>>>>> about an interesting case where a clean close is not possible when >>>>>>> there is >>>>>>> too much unread data. A fix for this will not break existing users. >>>>>>> Support >>>>>>> for ping/pong frames, and sending custom request headers with the >>>>>>> handshake >>>>>>> are popular requests for both the WebSocket and WebSocketStream APIs. >>>>>>> These >>>>>>> can be implemented without incompatible changes to the API (though on >>>>>>> the >>>>>>> server side they will cause much trouble). There are other open issues >>>>>>> at >>>>>>> https://github.com/ricea/websocketstream-explainer/issues but >>>>>>> nothing that needs to be addressed urgently. >>>>>>> >>>>>>> Link to entry on the Chrome Platform Status >>>>>>> https://chromestatus.com/feature/5189728691290112 >>>>>>> >>>>>>> Links to previous Intent discussions Intent to prototype: >>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/X7rWpAkMCyg/m/j6K7mEEwAgAJ >>>>>>> Intent >>>>>>> to Experiment: >>>>>>> https://groups.google.com/a/chromium.org/d/msg/blink-dev/SUaSJzLQ1Yc/jmk7A-maAAAJ >>>>>>> >>>>>>> >>>>>>> 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/CAC_ixdwX4dnvpwsOJ7nm%2BW6UYs%2BNwQ_gHZJD7yvzTcawD2Rw8w%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdwX4dnvpwsOJ7nm%2BW6UYs%2BNwQ_gHZJD7yvzTcawD2Rw8w%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/61e1ef29-5c9b-42de-83f6-d3ca931662bf%40chromium.org >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/61e1ef29-5c9b-42de-83f6-d3ca931662bf%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/CAC_ixdzNQY9FW8DfhkvOLkGRqzG3yJ7R%2Bi%3D%2BRiNnXMfheD2r-g%40mail.gmail.com.
