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.

Reply via email to