As an additional developer signal showing that developers want this, there's a polyfill: https://github.com/CarterLi/websocketstream-polyfill.
On Tue, Mar 5, 2024 at 10:10 AM Domenic Denicola <dome...@chromium.org> wrote: > LGTM2. > > I appreciate Adam's careful attention to all portions of the process here, > and also Alex's probing as to whether we're meeting the developer interest > portion. Although this would be more of a slam-dunk if we were able to get > that partner to comment publicly on their experience, I'm willing to take > Adam's word on it about the private feedback. > > Combined with the general positive sentiment, e.g. from Deno (which is a > server-side runtime, but I think we have a good amount of experience > showing that people like writing the same code across server and browser), > and in response to the 2020 article > <https://twitter.com/search?q=url%3Ahttps%3A%2F%2Fweb.dev%2Fwebsocketstream%2F&src=typed_query&f=live>, > and the repeated "when is this coming" comments in the tracking bug > <https://issues.chromium.org/issues/41470216>... I think we have enough > evidence that this will move the web forward in a positive way. > > With my API owner hat off, I'm also just happy about this API existing, as > I think it's generally good for the platform when we go back and take > older, but still popular technologies, and retrofit them with modern > capabilities and APIs like backpressure-supporting streams. It makes the > web feel more cohesive and well-designed. > > On Tuesday, March 5, 2024 at 8:46:59 AM UTC+9 Adam Rice wrote: > >> 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/51712f36-d16a-4b6e-baf9-da35b4785f04n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/51712f36-d16a-4b6e-baf9-da35b4785f04n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- Thomas Steiner, PhD—Developer Relations Engineer (blog.tomayac.com, toot.cafe/@tomayac) Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany Geschäftsführer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 ----- BEGIN PGP SIGNATURE ----- Version: GnuPG v2.4.3 (GNU/Linux) iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck 0fjumBl3DCharaCTersAttH3b0ttom.xKcd.cOm/1181. ----- END PGP SIGNATURE ----- -- 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/CALgRrLmPi%2BfdcLZ6UfCF3BRN0sdoGs8eOu9Y87%3DLikE94Qr%3D%3Dw%40mail.gmail.com.
