Re: [blink-dev] Re: Intent to Ship: WebSocketStream

[Yoav Weiss (@Shopify)]

LGTM3

On Tue, Mar 5, 2024 at 10:16 AM 'Thomas Steiner' via blink-dev <
blink-dev@chromium.org> wrote:

> As an additional developer signal showing that developers want this,
> there's a polyfill: https://github.com/CarterLi/websocketstream-polyfill.
>
> On Tue, Mar 5, 2024 at 10:10 AM Domenic Denicola 
> wrote:
>
>> 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
>> ,
>> and the repeated "when is this coming" comments in the tracking bug
>> ... 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 
>>> 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 
> wrote:
>
>> Hi,
>>
>> Any reason the PR for the spec hasn't landed yet?
>>
>> On Thu, Feb 15, 2024 at 7:54 AM Mike Taylor 
>> 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 
>>> 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 
 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
>> 

Re: [blink-dev] Re: Intent to Ship: WebSocketStream

['Thomas Steiner' via blink-dev]

As an additional developer signal showing that developers want this,
there's a polyfill: https://github.com/CarterLi/websocketstream-polyfill.

On Tue, Mar 5, 2024 at 10:10 AM Domenic Denicola 
wrote:

> 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
> ,
> and the repeated "when is this coming" comments in the tracking bug
> ... 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 
>> 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 
 wrote:

> Hi,
>
> Any reason the PR for the spec hasn't landed yet?
>
> On Thu, Feb 15, 2024 at 7:54 AM Mike Taylor 
> 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 
>> 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 
>>> 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
> 
>
> Search tags WebSocket
> , Streams
> 

Re: [blink-dev] Re: Intent to Ship: WebSocketStream

[Domenic Denicola]

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 
,
 
and the repeated "when is this coming" comments in the tracking bug 
... 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  
> 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  
>>> wrote:
>>>
 Hi,

 Any reason the PR for the spec hasn't landed yet?

 On Thu, Feb 15, 2024 at 7:54 AM Mike Taylor  
 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  
> 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  
>> 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 
 

 Search tags WebSocket 
 , Streams 
 , ReadableStream 
 , 
 WritableStream 
 

 TAG review https://github.com/w3ctag/design-reviews/issues/394

 TAG review status Pend

Re: [blink-dev] Re: Intent to Ship: WebSocketStream

[Adam Rice]

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  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 
>> wrote:
>>
>>> Hi,
>>>
>>> Any reason the PR for the spec hasn't landed yet?
>>>
>>> On Thu, Feb 15, 2024 at 7:54 AM Mike Taylor 
>>> 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 
 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 
> 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
>>> 
>>>
>>> Search tags WebSocket
>>> , Streams
>>> , ReadableStream
>>> ,
>>> 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

Re: [blink-dev] Re: Intent to Ship: WebSocketStream

[Alex Russell]

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  
> wrote:
>
>> Hi,
>>
>> Any reason the PR for the spec hasn't landed yet?
>>
>> On Thu, Feb 15, 2024 at 7:54 AM Mike Taylor  
>> 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  
>>> 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  
 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 
>> 
>>
>> Search tags WebSocket 
>> , Streams 
>> , ReadableStream 
>> , 
>> 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?

Re: [blink-dev] Re: Intent to Ship: WebSocketStream

[Adam Rice]

>
> 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  wrote:

> Hi,
>
> Any reason the PR for the spec hasn't landed yet?
>
> On Thu, Feb 15, 2024 at 7:54 AM Mike Taylor 
> 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  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 
>>> 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
> 
>
> Search tags WebSocket
> , Streams
> , ReadableStream
> ,
> 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
> 

Re: [blink-dev] Re: Intent to Ship: WebSocketStream

[Chris Harrelson]

Hi,

Any reason the PR for the spec hasn't landed yet?

On Thu, Feb 15, 2024 at 7:54 AM Mike Taylor  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  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 
>> 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
 

 Search tags WebSocket
 , Streams
 , ReadableStream
 , 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
 
 ? 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://b

Re: [blink-dev] Re: Intent to Ship: WebSocketStream

[Mike Taylor]

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  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
 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




Search tags

WebSocket
,
Streams ,
ReadableStream
,
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
   

Re: [blink-dev] Re: Intent to Ship: WebSocketStream

[Adam Rice]

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  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 
> 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
>>> 
>>>
>>> Search tags WebSocket 
>>> , Streams ,
>>> ReadableStream ,
>>> 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
>>> 
>>> ? 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.
>>>
>>

Re: [blink-dev] Re: Intent to Ship: WebSocketStream

[Mike Taylor]

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  
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




Search tags

WebSocket ,
Streams ,
ReadableStream
,
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

?

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 b

[blink-dev] Re: Intent to Ship: WebSocketStream

[Adam Rice]

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  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
>> 
>>
>> Search tagsWebSocket ,
>> Streams , ReadableStream
>> , 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
>> 
>> ?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
>> O

[blink-dev] Re: Intent to Ship: WebSocketStream

[Alex Russell]

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 
> 
>
> Search tagsWebSocket , 
> Streams , ReadableStream 
> , 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 
> 
> ?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