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 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_ixdwX4dnvpwsOJ7nm%2BW6UYs%2BNwQ_gHZJD7yvzTcawD2Rw8w%40mail.gmail.com.
