Contact emailsri...@chromium.org Explainer https://github.com/ricea/websocketstream-explainer/blob/master/README.md https://docs.google.com/document/d/1XuxEshh5VYBYm1qRVKordTamCOsR-uGQBCYFcHXP4L0/edit
Specificationhttps://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 componentBlink>Network>WebSockets <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork%3EWebSockets> Search tagsWebSocket <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 reviewhttps://github.com/w3ctag/design-reviews/issues/394 TAG review statusPending Chromium Trial NameWebSocketStream 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 nameWebSocketStream Requires code in //chrome?False Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=983030 MeasurementUse counter: https://chromestatus.com/metrics/feature/timeline/popularity/3018 Availability expectationThe feature is relatively straightforward to implement, so I would expect it to be available in other browsers within 12 months. Adoption expectationWe 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 discussionsIntent 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_ixdwofPbTe1DxcHrLik0WCJMszjQNb4KmhFongm3_5T_bbw%40mail.gmail.com.
