> > 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_ixdznjkWEuyV8aH6UK8bxLsEhCygnG0%2Bf_%3D-%2BDo2JjtjPZQ%40mail.gmail.com.
