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.
