Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-12-06 Thread Nidhi Jaju 
Hi Joe,

I'm really sorry for the delay in my reply!
These changes will be shipped in Chrome 98.

Best regards,
Nidhi

On Wed, Dec 1, 2021 at 5:14 AM Joe Medley  wrote:

> In which version is this shipping?
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>  816-678-7195
> *If an API's not documented it doesn't exist.*
>
>
> On Wed, Nov 24, 2021 at 8:21 AM Chris Harrelson 
> wrote:
>
>> LGTM3
>>
>> On Wed, Nov 24, 2021 at 6:18 AM Mike West  wrote:
>>
>>> LGTM2.
>>>
>>> Given that this has landed in both DOM and Streams with support from
>>> Mozilla, and WebKit has tacitly expressed support via their implementation,
>>> this is a pretty reasonable thing for us to follow along with. Thanks for
>>> iterating with others in the ecosystem to land on something folks were
>>> happy with!
>>>
>>> -mike
>>>
>>>
>>> On Wed, Nov 24, 2021 at 11:06 AM Yoav Weiss 
>>> wrote:
>>>
 LGTM1

 On Wed, Nov 24, 2021, 10:50 Nidhi Jaju  wrote:

> On Wed, Nov 24, 2021 at 1:43 PM Yoav Weiss 
> wrote:
>
>> Thanks for addressing the TAG's feedback!
>>
>>
>> On Wednesday, November 24, 2021 at 8:57:12 AM UTC+1 Nidhi Jaju wrote:
>>
>>> Hi all,
>>>
>>> Another update: based on the feedback we received from TAG as
>>> previously mentioned, we decided to remove the abortReason from
>>> WritableStreamDefaultController which was initially proposed, and 
>>> instead
>>> add an "abort reason" property
>>>  to
>>> AbortSignal which was specced in
>>> https://github.com/whatwg/dom/pull/1027. Related to this on the
>>> interface side, the static AbortSignal.abort()
>>>  as well as the
>>> AbortController.abort()
>>>  now take
>>> an optional reason argument. Gecko and WebKit folks and some developers
>>> have also expressed implementer's interest on the PR, and some have 
>>> gone on
>>> to update their browser implementation/polyfills already.
>>>
>>
>> Any specifics? Does this mean other browsers are now also shipping
>> AbortSignal for WritableStreams? Or did they just update their current
>> AbortSignal implementation with an "abort reason"?
>>
>
> Ah, sorry for the unclearness. I mean they (i.e. WebKit
> ,
> Deno
> ,
> and almost Node.js ) have
> updated their current AbortSignal implementation with an "abort reason". 
> As
> far as I'm aware, the signals related to shipping AbortSignal for
> WritableStreams itself remain unchanged from earlier on in this thread.
>

 Makes sense, thanks for clarifying!


>
>>
>>
>>>
>>> This was also integrated into the Streams standard in
>>> https://github.com/whatwg/streams/pull/1182. (FYI: the AbortSignal
>>> API is connected to various different standards, so there is also an
>>> ongoing effort to update those affected specs as well here
>>> .)
>>>
>>> I would like to resume the intent process based on these updates.
>>> Please let me know if you have any questions or thoughts.
>>>
>>> Thank you!
>>>
>>> Best regards,
>>> Nidhi
>>>
>>> On Thu, Oct 7, 2021 at 1:11 PM Yoav Weiss 
>>> wrote:
>>>
 After talking to Nidhi offline, we can consider this intent on hold
 until the feedback is addressed.

 On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju
 wrote:

> Hi,
>
> Just as an update, we have received some feedback on our TAG
> review (
> https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419),
> and hence we are having some discussions and deciding on next best 
> steps
> accordingly.
>
> Best regards,
> Nidhi
>
> On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju 
> wrote:
>
>>
>>
>> On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant 
>> wrote:
>>
>>> The Web Serial API is also interested in this capability. See
>>> the note on the abort algorithm when initializing the
>>> WritableStream
>>> .
>>> Reilly Grant | Software Engineer | reil...@chromium.org | Google
>>> Chrome 
>>>
>>>
>>> On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson <
>>> chris...@chromium.org> wrote:
>>>

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-11-30 Thread 'Joe Medley' via blink-dev 
In which version is this shipping?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Nov 24, 2021 at 8:21 AM Chris Harrelson 
wrote:

> LGTM3
>
> On Wed, Nov 24, 2021 at 6:18 AM Mike West  wrote:
>
>> LGTM2.
>>
>> Given that this has landed in both DOM and Streams with support from
>> Mozilla, and WebKit has tacitly expressed support via their implementation,
>> this is a pretty reasonable thing for us to follow along with. Thanks for
>> iterating with others in the ecosystem to land on something folks were
>> happy with!
>>
>> -mike
>>
>>
>> On Wed, Nov 24, 2021 at 11:06 AM Yoav Weiss 
>> wrote:
>>
>>> LGTM1
>>>
>>> On Wed, Nov 24, 2021, 10:50 Nidhi Jaju  wrote:
>>>
 On Wed, Nov 24, 2021 at 1:43 PM Yoav Weiss 
 wrote:

> Thanks for addressing the TAG's feedback!
>
>
> On Wednesday, November 24, 2021 at 8:57:12 AM UTC+1 Nidhi Jaju wrote:
>
>> Hi all,
>>
>> Another update: based on the feedback we received from TAG as
>> previously mentioned, we decided to remove the abortReason from
>> WritableStreamDefaultController which was initially proposed, and instead
>> add an "abort reason" property
>>  to
>> AbortSignal which was specced in
>> https://github.com/whatwg/dom/pull/1027. Related to this on the
>> interface side, the static AbortSignal.abort()
>>  as well as the
>> AbortController.abort()
>>  now take an
>> optional reason argument. Gecko and WebKit folks and some developers have
>> also expressed implementer's interest on the PR, and some have gone on to
>> update their browser implementation/polyfills already.
>>
>
> Any specifics? Does this mean other browsers are now also shipping
> AbortSignal for WritableStreams? Or did they just update their current
> AbortSignal implementation with an "abort reason"?
>

 Ah, sorry for the unclearness. I mean they (i.e. WebKit
 ,
 Deno
 ,
 and almost Node.js ) have
 updated their current AbortSignal implementation with an "abort reason". As
 far as I'm aware, the signals related to shipping AbortSignal for
 WritableStreams itself remain unchanged from earlier on in this thread.

>>>
>>> Makes sense, thanks for clarifying!
>>>
>>>

>
>
>>
>> This was also integrated into the Streams standard in
>> https://github.com/whatwg/streams/pull/1182. (FYI: the AbortSignal
>> API is connected to various different standards, so there is also an
>> ongoing effort to update those affected specs as well here
>> .)
>>
>> I would like to resume the intent process based on these updates.
>> Please let me know if you have any questions or thoughts.
>>
>> Thank you!
>>
>> Best regards,
>> Nidhi
>>
>> On Thu, Oct 7, 2021 at 1:11 PM Yoav Weiss 
>> wrote:
>>
>>> After talking to Nidhi offline, we can consider this intent on hold
>>> until the feedback is addressed.
>>>
>>> On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju wrote:
>>>
 Hi,

 Just as an update, we have received some feedback on our TAG review
 (
 https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419),
 and hence we are having some discussions and deciding on next best 
 steps
 accordingly.

 Best regards,
 Nidhi

 On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju 
 wrote:

>
>
> On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant 
> wrote:
>
>> The Web Serial API is also interested in this capability. See the
>> note on the abort algorithm when initializing the WritableStream
>> .
>> Reilly Grant | Software Engineer | reil...@chromium.org | Google
>> Chrome 
>>
>>
>> On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson <
>> chris...@chromium.org> wrote:
>>
>>>
>>>
>>> On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju <
>>> nidhij...@chromium.org> wrote:
>>>


 On Wed, Sep 1, 2021 at 10:54 PM Alex Russell <
 slightly...@chromium.org> wrote:

> Incremental features often benefit from TAG guidance. I'd feel
> better if this

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-11-24 Thread Chris Harrelson 
LGTM3

On Wed, Nov 24, 2021 at 6:18 AM Mike West  wrote:

> LGTM2.
>
> Given that this has landed in both DOM and Streams with support from
> Mozilla, and WebKit has tacitly expressed support via their implementation,
> this is a pretty reasonable thing for us to follow along with. Thanks for
> iterating with others in the ecosystem to land on something folks were
> happy with!
>
> -mike
>
>
> On Wed, Nov 24, 2021 at 11:06 AM Yoav Weiss 
> wrote:
>
>> LGTM1
>>
>> On Wed, Nov 24, 2021, 10:50 Nidhi Jaju  wrote:
>>
>>> On Wed, Nov 24, 2021 at 1:43 PM Yoav Weiss 
>>> wrote:
>>>
 Thanks for addressing the TAG's feedback!


 On Wednesday, November 24, 2021 at 8:57:12 AM UTC+1 Nidhi Jaju wrote:

> Hi all,
>
> Another update: based on the feedback we received from TAG as
> previously mentioned, we decided to remove the abortReason from
> WritableStreamDefaultController which was initially proposed, and instead
> add an "abort reason" property
>  to
> AbortSignal which was specced in
> https://github.com/whatwg/dom/pull/1027. Related to this on the
> interface side, the static AbortSignal.abort()
>  as well as the
> AbortController.abort()
>  now take an
> optional reason argument. Gecko and WebKit folks and some developers have
> also expressed implementer's interest on the PR, and some have gone on to
> update their browser implementation/polyfills already.
>

 Any specifics? Does this mean other browsers are now also shipping
 AbortSignal for WritableStreams? Or did they just update their current
 AbortSignal implementation with an "abort reason"?

>>>
>>> Ah, sorry for the unclearness. I mean they (i.e. WebKit
>>> ,
>>> Deno
>>> ,
>>> and almost Node.js ) have
>>> updated their current AbortSignal implementation with an "abort reason". As
>>> far as I'm aware, the signals related to shipping AbortSignal for
>>> WritableStreams itself remain unchanged from earlier on in this thread.
>>>
>>
>> Makes sense, thanks for clarifying!
>>
>>
>>>


>
> This was also integrated into the Streams standard in
> https://github.com/whatwg/streams/pull/1182. (FYI: the AbortSignal
> API is connected to various different standards, so there is also an
> ongoing effort to update those affected specs as well here
> .)
>
> I would like to resume the intent process based on these updates.
> Please let me know if you have any questions or thoughts.
>
> Thank you!
>
> Best regards,
> Nidhi
>
> On Thu, Oct 7, 2021 at 1:11 PM Yoav Weiss 
> wrote:
>
>> After talking to Nidhi offline, we can consider this intent on hold
>> until the feedback is addressed.
>>
>> On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju wrote:
>>
>>> Hi,
>>>
>>> Just as an update, we have received some feedback on our TAG review (
>>> https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419),
>>> and hence we are having some discussions and deciding on next best steps
>>> accordingly.
>>>
>>> Best regards,
>>> Nidhi
>>>
>>> On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju 
>>> wrote:
>>>


 On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant 
 wrote:

> The Web Serial API is also interested in this capability. See the
> note on the abort algorithm when initializing the WritableStream
> .
> Reilly Grant | Software Engineer | reil...@chromium.org | Google
> Chrome 
>
>
> On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson <
> chris...@chromium.org> wrote:
>
>>
>>
>> On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju 
>> wrote:
>>
>>>
>>>
>>> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell <
>>> slightly...@chromium.org> wrote:
>>>
 Incremental features often benefit from TAG guidance. I'd feel
 better if this intent at least cited prior TAG reviews in this 
 area or
 filed an FYI (with potential for TAG to request full review).

 If it was covered in a previous review of WritableStreams, that
 would also be good to know.

>>>
>>> This feature wasn't covered in a previous review of
>>> WritableStreams, so I have

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-11-24 Thread Mike West 
LGTM2.

Given that this has landed in both DOM and Streams with support from
Mozilla, and WebKit has tacitly expressed support via their implementation,
this is a pretty reasonable thing for us to follow along with. Thanks for
iterating with others in the ecosystem to land on something folks were
happy with!

-mike


On Wed, Nov 24, 2021 at 11:06 AM Yoav Weiss  wrote:

> LGTM1
>
> On Wed, Nov 24, 2021, 10:50 Nidhi Jaju  wrote:
>
>> On Wed, Nov 24, 2021 at 1:43 PM Yoav Weiss 
>> wrote:
>>
>>> Thanks for addressing the TAG's feedback!
>>>
>>>
>>> On Wednesday, November 24, 2021 at 8:57:12 AM UTC+1 Nidhi Jaju wrote:
>>>
 Hi all,

 Another update: based on the feedback we received from TAG as
 previously mentioned, we decided to remove the abortReason from
 WritableStreamDefaultController which was initially proposed, and instead
 add an "abort reason" property
  to AbortSignal
 which was specced in https://github.com/whatwg/dom/pull/1027. Related
 to this on the interface side, the static AbortSignal.abort()
  as well as the
 AbortController.abort()
  now take an
 optional reason argument. Gecko and WebKit folks and some developers have
 also expressed implementer's interest on the PR, and some have gone on to
 update their browser implementation/polyfills already.

>>>
>>> Any specifics? Does this mean other browsers are now also shipping
>>> AbortSignal for WritableStreams? Or did they just update their current
>>> AbortSignal implementation with an "abort reason"?
>>>
>>
>> Ah, sorry for the unclearness. I mean they (i.e. WebKit
>> ,
>> Deno
>> ,
>> and almost Node.js ) have
>> updated their current AbortSignal implementation with an "abort reason". As
>> far as I'm aware, the signals related to shipping AbortSignal for
>> WritableStreams itself remain unchanged from earlier on in this thread.
>>
>
> Makes sense, thanks for clarifying!
>
>
>>
>>>
>>>

 This was also integrated into the Streams standard in
 https://github.com/whatwg/streams/pull/1182. (FYI: the AbortSignal API
 is connected to various different standards, so there is also an ongoing
 effort to update those affected specs as well here
 .)

 I would like to resume the intent process based on these updates.
 Please let me know if you have any questions or thoughts.

 Thank you!

 Best regards,
 Nidhi

 On Thu, Oct 7, 2021 at 1:11 PM Yoav Weiss 
 wrote:

> After talking to Nidhi offline, we can consider this intent on hold
> until the feedback is addressed.
>
> On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju wrote:
>
>> Hi,
>>
>> Just as an update, we have received some feedback on our TAG review (
>> https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419),
>> and hence we are having some discussions and deciding on next best steps
>> accordingly.
>>
>> Best regards,
>> Nidhi
>>
>> On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju 
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant 
>>> wrote:
>>>
 The Web Serial API is also interested in this capability. See the
 note on the abort algorithm when initializing the WritableStream
 .
 Reilly Grant | Software Engineer | reil...@chromium.org | Google
 Chrome 


 On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson <
 chris...@chromium.org> wrote:

>
>
> On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju 
> wrote:
>
>>
>>
>> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell <
>> slightly...@chromium.org> wrote:
>>
>>> Incremental features often benefit from TAG guidance. I'd feel
>>> better if this intent at least cited prior TAG reviews in this area 
>>> or
>>> filed an FYI (with potential for TAG to request full review).
>>>
>>> If it was covered in a previous review of WritableStreams, that
>>> would also be good to know.
>>>
>>
>> This feature wasn't covered in a previous review of
>> WritableStreams, so I have filed a new TAG review:
>> https://github.com/w3ctag/design-reviews/issues/672
>>
>>
>>>
>>> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss 
>>> wrote:
>>>

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-11-24 Thread Yoav Weiss 
LGTM1

On Wed, Nov 24, 2021, 10:50 Nidhi Jaju  wrote:

> On Wed, Nov 24, 2021 at 1:43 PM Yoav Weiss  wrote:
>
>> Thanks for addressing the TAG's feedback!
>>
>>
>> On Wednesday, November 24, 2021 at 8:57:12 AM UTC+1 Nidhi Jaju wrote:
>>
>>> Hi all,
>>>
>>> Another update: based on the feedback we received from TAG as previously
>>> mentioned, we decided to remove the abortReason from
>>> WritableStreamDefaultController which was initially proposed, and instead
>>> add an "abort reason" property
>>>  to AbortSignal
>>> which was specced in https://github.com/whatwg/dom/pull/1027. Related
>>> to this on the interface side, the static AbortSignal.abort()
>>>  as well as the
>>> AbortController.abort()
>>>  now take an
>>> optional reason argument. Gecko and WebKit folks and some developers have
>>> also expressed implementer's interest on the PR, and some have gone on to
>>> update their browser implementation/polyfills already.
>>>
>>
>> Any specifics? Does this mean other browsers are now also shipping
>> AbortSignal for WritableStreams? Or did they just update their current
>> AbortSignal implementation with an "abort reason"?
>>
>
> Ah, sorry for the unclearness. I mean they (i.e. WebKit
> ,
> Deno
> ,
> and almost Node.js ) have
> updated their current AbortSignal implementation with an "abort reason". As
> far as I'm aware, the signals related to shipping AbortSignal for
> WritableStreams itself remain unchanged from earlier on in this thread.
>

Makes sense, thanks for clarifying!


>
>>
>>
>>>
>>> This was also integrated into the Streams standard in
>>> https://github.com/whatwg/streams/pull/1182. (FYI: the AbortSignal API
>>> is connected to various different standards, so there is also an ongoing
>>> effort to update those affected specs as well here
>>> .)
>>>
>>> I would like to resume the intent process based on these updates. Please
>>> let me know if you have any questions or thoughts.
>>>
>>> Thank you!
>>>
>>> Best regards,
>>> Nidhi
>>>
>>> On Thu, Oct 7, 2021 at 1:11 PM Yoav Weiss 
>>> wrote:
>>>
 After talking to Nidhi offline, we can consider this intent on hold
 until the feedback is addressed.

 On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju wrote:

> Hi,
>
> Just as an update, we have received some feedback on our TAG review (
> https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419),
> and hence we are having some discussions and deciding on next best steps
> accordingly.
>
> Best regards,
> Nidhi
>
> On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju 
> wrote:
>
>>
>>
>> On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant 
>> wrote:
>>
>>> The Web Serial API is also interested in this capability. See the
>>> note on the abort algorithm when initializing the WritableStream
>>> .
>>> Reilly Grant | Software Engineer | reil...@chromium.org | Google
>>> Chrome 
>>>
>>>
>>> On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson <
>>> chris...@chromium.org> wrote:
>>>


 On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju 
 wrote:

>
>
> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell <
> slightly...@chromium.org> wrote:
>
>> Incremental features often benefit from TAG guidance. I'd feel
>> better if this intent at least cited prior TAG reviews in this area 
>> or
>> filed an FYI (with potential for TAG to request full review).
>>
>> If it was covered in a previous review of WritableStreams, that
>> would also be good to know.
>>
>
> This feature wasn't covered in a previous review of
> WritableStreams, so I have filed a new TAG review:
> https://github.com/w3ctag/design-reviews/issues/672
>
>
>>
>> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju <
>>> nidhij...@chromium.org> wrote:
>>>
 Contact emailsnidhij...@chromium.org, ri...@chromium.org,
 yhir...@chromium.org

 Explainer
 https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md


>>>

 Specification

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-11-24 Thread Nidhi Jaju 
On Wed, Nov 24, 2021 at 1:43 PM Yoav Weiss  wrote:

> Thanks for addressing the TAG's feedback!
>
>
> On Wednesday, November 24, 2021 at 8:57:12 AM UTC+1 Nidhi Jaju wrote:
>
>> Hi all,
>>
>> Another update: based on the feedback we received from TAG as previously
>> mentioned, we decided to remove the abortReason from
>> WritableStreamDefaultController which was initially proposed, and instead
>> add an "abort reason" property
>>  to AbortSignal
>> which was specced in https://github.com/whatwg/dom/pull/1027. Related to
>> this on the interface side, the static AbortSignal.abort()
>>  as well as the
>> AbortController.abort()
>>  now take an
>> optional reason argument. Gecko and WebKit folks and some developers have
>> also expressed implementer's interest on the PR, and some have gone on to
>> update their browser implementation/polyfills already.
>>
>
> Any specifics? Does this mean other browsers are now also shipping
> AbortSignal for WritableStreams? Or did they just update their current
> AbortSignal implementation with an "abort reason"?
>

Ah, sorry for the unclearness. I mean they (i.e. WebKit
,
Deno
,
and almost Node.js ) have
updated their current AbortSignal implementation with an "abort reason". As
far as I'm aware, the signals related to shipping AbortSignal for
WritableStreams itself remain unchanged from earlier on in this thread.


>
>
>>
>> This was also integrated into the Streams standard in
>> https://github.com/whatwg/streams/pull/1182. (FYI: the AbortSignal API
>> is connected to various different standards, so there is also an ongoing
>> effort to update those affected specs as well here
>> .)
>>
>> I would like to resume the intent process based on these updates. Please
>> let me know if you have any questions or thoughts.
>>
>> Thank you!
>>
>> Best regards,
>> Nidhi
>>
>> On Thu, Oct 7, 2021 at 1:11 PM Yoav Weiss  wrote:
>>
>>> After talking to Nidhi offline, we can consider this intent on hold
>>> until the feedback is addressed.
>>>
>>> On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju wrote:
>>>
 Hi,

 Just as an update, we have received some feedback on our TAG review (
 https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419),
 and hence we are having some discussions and deciding on next best steps
 accordingly.

 Best regards,
 Nidhi

 On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju 
 wrote:

>
>
> On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant 
> wrote:
>
>> The Web Serial API is also interested in this capability. See the
>> note on the abort algorithm when initializing the WritableStream
>> .
>> Reilly Grant | Software Engineer | reil...@chromium.org | Google
>> Chrome 
>>
>>
>> On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson <
>> chris...@chromium.org> wrote:
>>
>>>
>>>
>>> On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju 
>>> wrote:
>>>


 On Wed, Sep 1, 2021 at 10:54 PM Alex Russell <
 slightly...@chromium.org> wrote:

> Incremental features often benefit from TAG guidance. I'd feel
> better if this intent at least cited prior TAG reviews in this area or
> filed an FYI (with potential for TAG to request full review).
>
> If it was covered in a previous review of WritableStreams, that
> would also be good to know.
>

 This feature wasn't covered in a previous review of
 WritableStreams, so I have filed a new TAG review:
 https://github.com/w3ctag/design-reviews/issues/672


>
> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss 
> wrote:
>
>>
>>
>> On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju <
>> nidhij...@chromium.org> wrote:
>>
>>> Contact emailsnidhij...@chromium.org, ri...@chromium.org,
>>> yhir...@chromium.org
>>>
>>> Explainer
>>> https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
>>>
>>>
>>
>>>
>>> Specification
>>> https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal
>>>
>>> Summary
>>>
>>> The streams APIs provide ubiquitous, interoperable primitives
>>> for creating, composing, and consuming streams of data. This change 
>>> permits

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-11-24 Thread Yoav Weiss 
Thanks for addressing the TAG's feedback!


On Wednesday, November 24, 2021 at 8:57:12 AM UTC+1 Nidhi Jaju wrote:

> Hi all,
>
> Another update: based on the feedback we received from TAG as previously 
> mentioned, we decided to remove the abortReason from 
> WritableStreamDefaultController which was initially proposed, and instead 
> add an "abort reason" property 
>  to AbortSignal 
> which was specced in https://github.com/whatwg/dom/pull/1027. Related to 
> this on the interface side, the static AbortSignal.abort() 
>  as well as the 
> AbortController.abort() 
>  now take an 
> optional reason argument. Gecko and WebKit folks and some developers have 
> also expressed implementer's interest on the PR, and some have gone on to 
> update their browser implementation/polyfills already.
>

Any specifics? Does this mean other browsers are now also shipping 
AbortSignal for WritableStreams? Or did they just update their current 
AbortSignal implementation with an "abort reason"?
 

>
> This was also integrated into the Streams standard in 
> https://github.com/whatwg/streams/pull/1182. (FYI: the AbortSignal API is 
> connected to various different standards, so there is also an ongoing 
> effort to update those affected specs as well here 
> .)
>
> I would like to resume the intent process based on these updates. Please 
> let me know if you have any questions or thoughts.
>
> Thank you!
>
> Best regards,
> Nidhi
>
> On Thu, Oct 7, 2021 at 1:11 PM Yoav Weiss  wrote:
>
>> After talking to Nidhi offline, we can consider this intent on hold until 
>> the feedback is addressed.
>>
>> On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju wrote:
>>
>>> Hi, 
>>>
>>> Just as an update, we have received some feedback on our TAG review (
>>> https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419),
>>>  
>>> and hence we are having some discussions and deciding on next best steps 
>>> accordingly.
>>>
>>> Best regards,
>>> Nidhi
>>>
>>> On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju  
>>> wrote:
>>>


 On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant  
 wrote:

> The Web Serial API is also interested in this capability. See the note 
> on the abort algorithm when initializing the WritableStream 
> .
> Reilly Grant | Software Engineer | reil...@chromium.org | Google 
> Chrome 
>
>
> On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson  
> wrote:
>
>>
>>
>> On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju  
>> wrote:
>>
>>>
>>>
>>> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell <
>>> slightly...@chromium.org> wrote:
>>>
 Incremental features often benefit from TAG guidance. I'd feel 
 better if this intent at least cited prior TAG reviews in this area or 
 filed an FYI (with potential for TAG to request full review).

 If it was covered in a previous review of WritableStreams, that 
 would also be good to know.

>>>
>>> This feature wasn't covered in a previous review of WritableStreams, 
>>> so I have filed a new TAG review: 
>>> https://github.com/w3ctag/design-reviews/issues/672
>>>  
>>>

 On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss  
 wrote:

>
>
> On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju  
> wrote:
>
>> Contact emailsnidhij...@chromium.org, ri...@chromium.org, 
>> yhir...@chromium.org
>>
>> Explainer
>> https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
>>   
>>
>
>>
>> Specification
>> https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal
>>
>> Summary
>>
>> The streams APIs provide ubiquitous, interoperable primitives for 
>> creating, composing, and consuming streams of data. This change 
>> permits an 
>> underlying sink to rapidly abort an ongoing write or close when 
>> requested 
>> by the writer.
>>
>>
>> Previously, when writer.abort() was called, a long-running write 
>> would still have to continue to completion before the stream could 
>> be 
>> aborted. With this change, the write can be aborted immediately.
>>
>
> Am I correct in assuming that the stream developer would have to 
> change their code in order for that to happen, and if they won't, the 
> current behavior won't change?
>

>>> Yes, that's correct.
>>>
>>>  
>
>>

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-11-23 Thread Nidhi Jaju 
Hi all,

Another update: based on the feedback we received from TAG as previously
mentioned, we decided to remove the abortReason from
WritableStreamDefaultController which was initially proposed, and instead
add an "abort reason" property
 to AbortSignal
which was specced in https://github.com/whatwg/dom/pull/1027. Related to
this on the interface side, the static AbortSignal.abort()
 as well as the
AbortController.abort()
 now take an
optional reason argument. Gecko and WebKit folks and some developers have
also expressed implementer's interest on the PR, and some have gone on to
update their browser implementation/polyfills already.

This was also integrated into the Streams standard in
https://github.com/whatwg/streams/pull/1182. (FYI: the AbortSignal API is
connected to various different standards, so there is also an ongoing
effort to update those affected specs as well here
.)

I would like to resume the intent process based on these updates. Please
let me know if you have any questions or thoughts.

Thank you!

Best regards,
Nidhi

On Thu, Oct 7, 2021 at 1:11 PM Yoav Weiss  wrote:

> After talking to Nidhi offline, we can consider this intent on hold until
> the feedback is addressed.
>
> On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju wrote:
>
>> Hi,
>>
>> Just as an update, we have received some feedback on our TAG review (
>> https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419),
>> and hence we are having some discussions and deciding on next best steps
>> accordingly.
>>
>> Best regards,
>> Nidhi
>>
>> On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju 
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant 
>>> wrote:
>>>
 The Web Serial API is also interested in this capability. See the note
 on the abort algorithm when initializing the WritableStream
 .
 Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome
 


 On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson 
 wrote:

>
>
> On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju 
> wrote:
>
>>
>>
>> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell <
>> slightly...@chromium.org> wrote:
>>
>>> Incremental features often benefit from TAG guidance. I'd feel
>>> better if this intent at least cited prior TAG reviews in this area or
>>> filed an FYI (with potential for TAG to request full review).
>>>
>>> If it was covered in a previous review of WritableStreams, that
>>> would also be good to know.
>>>
>>
>> This feature wasn't covered in a previous review of WritableStreams,
>> so I have filed a new TAG review:
>> https://github.com/w3ctag/design-reviews/issues/672
>>
>>
>>>
>>> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss 
>>> wrote:
>>>


 On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju 
 wrote:

> Contact emailsnidhij...@chromium.org, ri...@chromium.org,
> yhir...@chromium.org
>
> Explainer
> https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
>
>

>
> Specification
> https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal
>
> Summary
>
> The streams APIs provide ubiquitous, interoperable primitives for
> creating, composing, and consuming streams of data. This change 
> permits an
> underlying sink to rapidly abort an ongoing write or close when 
> requested
> by the writer.
>
>
> Previously, when writer.abort() was called, a long-running write
> would still have to continue to completion before the stream could be
> aborted. With this change, the write can be aborted immediately.
>

 Am I correct in assuming that the stream developer would have to
 change their code in order for that to happen, and if they won't, the
 current behavior won't change?

>>>
>> Yes, that's correct.
>>
>>

> In addition to being exposed to streams authored in JavaScript,
> this facility will also be used by platform-provided streams such as
> WebTransport.
>
> Blink componentBlink>Network>StreamsAPI
> 
>
> TAG reviewNot needed as this is an incremental improvement to an
> existing feature.
>
> TAG review statusNot applicable
>
> Risks
>

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-10-07 Thread Yoav Weiss 
After talking to Nidhi offline, we can consider this intent on hold until 
the feedback is addressed.

On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju wrote:

> Hi, 
>
> Just as an update, we have received some feedback on our TAG review (
> https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419), 
> and hence we are having some discussions and deciding on next best steps 
> accordingly.
>
> Best regards,
> Nidhi
>
> On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju  wrote:
>
>>
>>
>> On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant  wrote:
>>
>>> The Web Serial API is also interested in this capability. See the note 
>>> on the abort algorithm when initializing the WritableStream 
>>> .
>>> Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome 
>>> 
>>>
>>>
>>> On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson  
>>> wrote:
>>>


 On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju  
 wrote:

>
>
> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell  
> wrote:
>
>> Incremental features often benefit from TAG guidance. I'd feel better 
>> if this intent at least cited prior TAG reviews in this area or filed an 
>> FYI (with potential for TAG to request full review).
>>
>> If it was covered in a previous review of WritableStreams, that would 
>> also be good to know.
>>
>
> This feature wasn't covered in a previous review of WritableStreams, 
> so I have filed a new TAG review: 
> https://github.com/w3ctag/design-reviews/issues/672
>  
>
>>
>> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss  
>> wrote:
>>
>>>
>>>
>>> On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju  
>>> wrote:
>>>
 Contact emailsnidhij...@chromium.org, ri...@chromium.org, 
 yhir...@chromium.org

 Explainer
 https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
   

>>>

 Specification
 https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal

 Summary

 The streams APIs provide ubiquitous, interoperable primitives for 
 creating, composing, and consuming streams of data. This change 
 permits an 
 underlying sink to rapidly abort an ongoing write or close when 
 requested 
 by the writer.


 Previously, when writer.abort() was called, a long-running write 
 would still have to continue to completion before the stream could be 
 aborted. With this change, the write can be aborted immediately.

>>>
>>> Am I correct in assuming that the stream developer would have to 
>>> change their code in order for that to happen, and if they won't, the 
>>> current behavior won't change?
>>>
>>
> Yes, that's correct.
>
>  
>>>
 In addition to being exposed to streams authored in JavaScript, 
 this facility will also be used by platform-provided streams such as 
 WebTransport.

 Blink componentBlink>Network>StreamsAPI 
 

 TAG reviewNot needed as this is an incremental improvement to an 
 existing feature.

 TAG review statusNot applicable

 Risks
 Interoperability and Compatibility

 Low risk because streams has already been standardised for a long 
 time (since around 2014). Other browsers have implemented other parts 
 of 
 the standard, and they will most likely also adapt this feature as 
 well 
 soon.

 Gecko: Positive (
 https://github.com/whatwg/streams/pull/1132#issuecomment-867114529 
 )
  
 Mozilla is supportive of Streams but has not yet shipped 
 WritableStream. It 
 is expected that they will include this feature when they do. They 
 have 
 also expressed interest in implementing WebTransport, and therefore 
 are 
 supportive of this feature.

>>>
>>> While such comments don't typically count as a position, combining 
>>> them with https://github.com/mozilla/standards-positions/issues/167 
>>> seems reasonable, given the size of this change.
>>>
>>
 That said, could you comment on issue 167 giving at least an FYI that 
 this intent is happening?

>>>
>> Yes, I just left a comment on the issue. (
>> https://github.com/mozilla/standards-positions/issues/167#issuecomment-912184900
>> )
>>  
>>
>>>  

>  
>>>

 WebKit: No signal

>>>
>>>

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-09-15 Thread Nidhi Jaju 
Hi,

Just as an update, we have received some feedback on our TAG review (
https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419),
and hence we are having some discussions and deciding on next best steps
accordingly.

Best regards,
Nidhi

On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju  wrote:

>
>
> On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant  wrote:
>
>> The Web Serial API is also interested in this capability. See the note on
>> the abort algorithm when initializing the WritableStream
>> .
>> Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome
>> 
>>
>>
>> On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson 
>> wrote:
>>
>>>
>>>
>>> On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju 
>>> wrote:
>>>


 On Wed, Sep 1, 2021 at 10:54 PM Alex Russell 
 wrote:

> Incremental features often benefit from TAG guidance. I'd feel better
> if this intent at least cited prior TAG reviews in this area or filed an
> FYI (with potential for TAG to request full review).
>
> If it was covered in a previous review of WritableStreams, that would
> also be good to know.
>

 This feature wasn't covered in a previous review of WritableStreams, so
 I have filed a new TAG review:
 https://github.com/w3ctag/design-reviews/issues/672


>
> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss 
> wrote:
>
>>
>>
>> On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju 
>> wrote:
>>
>>> Contact emailsnidhij...@chromium.org, ri...@chromium.org,
>>> yhir...@chromium.org
>>>
>>> Explainer
>>> https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
>>>
>>>
>>
>>>
>>> Specification
>>> https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal
>>>
>>> Summary
>>>
>>> The streams APIs provide ubiquitous, interoperable primitives for
>>> creating, composing, and consuming streams of data. This change permits 
>>> an
>>> underlying sink to rapidly abort an ongoing write or close when 
>>> requested
>>> by the writer.
>>>
>>>
>>> Previously, when writer.abort() was called, a long-running write
>>> would still have to continue to completion before the stream could be
>>> aborted. With this change, the write can be aborted immediately.
>>>
>>
>> Am I correct in assuming that the stream developer would have to
>> change their code in order for that to happen, and if they won't, the
>> current behavior won't change?
>>
>
 Yes, that's correct.


>>
>>> In addition to being exposed to streams authored in JavaScript, this
>>> facility will also be used by platform-provided streams such as
>>> WebTransport.
>>>
>>> Blink componentBlink>Network>StreamsAPI
>>> 
>>>
>>> TAG reviewNot needed as this is an incremental improvement to an
>>> existing feature.
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Low risk because streams has already been standardised for a long
>>> time (since around 2014). Other browsers have implemented other parts of
>>> the standard, and they will most likely also adapt this feature as well
>>> soon.
>>>
>>> Gecko: Positive (
>>> https://github.com/whatwg/streams/pull/1132#issuecomment-867114529
>>> )
>>> Mozilla is supportive of Streams but has not yet shipped 
>>> WritableStream. It
>>> is expected that they will include this feature when they do. They have
>>> also expressed interest in implementing WebTransport, and therefore are
>>> supportive of this feature.
>>>
>>
>> While such comments don't typically count as a position, combining
>> them with https://github.com/mozilla/standards-positions/issues/167
>> seems reasonable, given the size of this change.
>>
>
>>> That said, could you comment on issue 167 giving at least an FYI that
>>> this intent is happening?
>>>
>>
> Yes, I just left a comment on the issue. (
> https://github.com/mozilla/standards-positions/issues/167#issuecomment-912184900
> )
>
>
>>
>>>

>>
>>>
>>> WebKit: No signal
>>>
>>
>> Have you reached out? https://bit.ly/blink-signals
>>
>
 I have requested for WebKit's position here:
 https://lists.webkit.org/pipermail/webkit-dev/2021-September/031977.html


>
>>
>>>
>>> Web developers: No signals
>>>
>>
>> Have you reached out? https://goo.gle/developer-signals
>>
>
 Mattias Buelens has shown positive support here:

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-09-02 Thread Nidhi Jaju 
On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant  wrote:

> The Web Serial API is also interested in this capability. See the note on
> the abort algorithm when initializing the WritableStream
> .
> Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome
> 
>
>
> On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson 
> wrote:
>
>>
>>
>> On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju  wrote:
>>
>>>
>>>
>>> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell 
>>> wrote:
>>>
 Incremental features often benefit from TAG guidance. I'd feel better
 if this intent at least cited prior TAG reviews in this area or filed an
 FYI (with potential for TAG to request full review).

 If it was covered in a previous review of WritableStreams, that would
 also be good to know.

>>>
>>> This feature wasn't covered in a previous review of WritableStreams, so
>>> I have filed a new TAG review:
>>> https://github.com/w3ctag/design-reviews/issues/672
>>>
>>>

 On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss  wrote:

>
>
> On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju 
> wrote:
>
>> Contact emailsnidhij...@chromium.org, ri...@chromium.org,
>> yhir...@chromium.org
>>
>> Explainer
>> https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
>>
>>
>
>>
>> Specification
>> https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal
>>
>> Summary
>>
>> The streams APIs provide ubiquitous, interoperable primitives for
>> creating, composing, and consuming streams of data. This change permits 
>> an
>> underlying sink to rapidly abort an ongoing write or close when requested
>> by the writer.
>>
>>
>> Previously, when writer.abort() was called, a long-running write
>> would still have to continue to completion before the stream could be
>> aborted. With this change, the write can be aborted immediately.
>>
>
> Am I correct in assuming that the stream developer would have to
> change their code in order for that to happen, and if they won't, the
> current behavior won't change?
>

>>> Yes, that's correct.
>>>
>>>
>
>> In addition to being exposed to streams authored in JavaScript, this
>> facility will also be used by platform-provided streams such as
>> WebTransport.
>>
>> Blink componentBlink>Network>StreamsAPI
>> 
>>
>> TAG reviewNot needed as this is an incremental improvement to an
>> existing feature.
>>
>> TAG review statusNot applicable
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Low risk because streams has already been standardised for a long
>> time (since around 2014). Other browsers have implemented other parts of
>> the standard, and they will most likely also adapt this feature as well
>> soon.
>>
>> Gecko: Positive (
>> https://github.com/whatwg/streams/pull/1132#issuecomment-867114529
>> )
>> Mozilla is supportive of Streams but has not yet shipped WritableStream. 
>> It
>> is expected that they will include this feature when they do. They have
>> also expressed interest in implementing WebTransport, and therefore are
>> supportive of this feature.
>>
>
> While such comments don't typically count as a position, combining
> them with https://github.com/mozilla/standards-positions/issues/167
> seems reasonable, given the size of this change.
>

>> That said, could you comment on issue 167 giving at least an FYI that
>> this intent is happening?
>>
>
Yes, I just left a comment on the issue. (
https://github.com/mozilla/standards-positions/issues/167#issuecomment-912184900
)


>
>>
>>>
>
>>
>> WebKit: No signal
>>
>
> Have you reached out? https://bit.ly/blink-signals
>

>>> I have requested for WebKit's position here:
>>> https://lists.webkit.org/pipermail/webkit-dev/2021-September/031977.html
>>>
>>>

>
>>
>> Web developers: No signals
>>
>
> Have you reached out? https://goo.gle/developer-signals
>

>>> Mattias Buelens has shown positive support here:
>>> https://github.com/whatwg/streams/issues/1015#issuecomment-531188273
>>> 
>>>
>>>

>
>>
>> Ergonomics
>>
>> A lot of design efforts have been made into making the streams API
>> easy to use. Additionally, this feature is only a small change to the
>> existing streams API that developers are used to. An underlying sink 
>> which
>> doesn't observe the controller.signal will continue to have the

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-09-02 Thread Reilly Grant 
The Web Serial API is also interested in this capability. See the note on
the abort algorithm when initializing the WritableStream
.
Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome



On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson 
wrote:

>
>
> On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju  wrote:
>
>>
>>
>> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell 
>> wrote:
>>
>>> Incremental features often benefit from TAG guidance. I'd feel better if
>>> this intent at least cited prior TAG reviews in this area or filed an FYI
>>> (with potential for TAG to request full review).
>>>
>>> If it was covered in a previous review of WritableStreams, that would
>>> also be good to know.
>>>
>>
>> This feature wasn't covered in a previous review of WritableStreams, so I
>> have filed a new TAG review:
>> https://github.com/w3ctag/design-reviews/issues/672
>>
>>
>>>
>>> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss  wrote:
>>>


 On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju 
 wrote:

> Contact emailsnidhij...@chromium.org, ri...@chromium.org,
> yhir...@chromium.org
>
> Explainer
> https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
>
>

>
> Specification
> https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal
>
> Summary
>
> The streams APIs provide ubiquitous, interoperable primitives for
> creating, composing, and consuming streams of data. This change permits an
> underlying sink to rapidly abort an ongoing write or close when requested
> by the writer.
>
>
> Previously, when writer.abort() was called, a long-running write would
> still have to continue to completion before the stream could be aborted.
> With this change, the write can be aborted immediately.
>

 Am I correct in assuming that the stream developer would have to change
 their code in order for that to happen, and if they won't, the current
 behavior won't change?

>>>
>> Yes, that's correct.
>>
>>

> In addition to being exposed to streams authored in JavaScript, this
> facility will also be used by platform-provided streams such as
> WebTransport.
>
> Blink componentBlink>Network>StreamsAPI
> 
>
> TAG reviewNot needed as this is an incremental improvement to an
> existing feature.
>
> TAG review statusNot applicable
>
> Risks
> Interoperability and Compatibility
>
> Low risk because streams has already been standardised for a long time
> (since around 2014). Other browsers have implemented other parts of the
> standard, and they will most likely also adapt this feature as well soon.
>
> Gecko: Positive (
> https://github.com/whatwg/streams/pull/1132#issuecomment-867114529
> )
> Mozilla is supportive of Streams but has not yet shipped WritableStream. 
> It
> is expected that they will include this feature when they do. They have
> also expressed interest in implementing WebTransport, and therefore are
> supportive of this feature.
>

 While such comments don't typically count as a position, combining them
 with https://github.com/mozilla/standards-positions/issues/167 seems
 reasonable, given the size of this change.

>>>
> That said, could you comment on issue 167 giving at least an FYI that this
> intent is happening?
>
>
>>

>
> WebKit: No signal
>

 Have you reached out? https://bit.ly/blink-signals

>>>
>> I have requested for WebKit's position here:
>> https://lists.webkit.org/pipermail/webkit-dev/2021-September/031977.html
>>
>>
>>>

>
> Web developers: No signals
>

 Have you reached out? https://goo.gle/developer-signals

>>>
>> Mattias Buelens has shown positive support here:
>> https://github.com/whatwg/streams/issues/1015#issuecomment-531188273
>> 
>>
>>
>>>

>
> Ergonomics
>
> A lot of design efforts have been made into making the streams API
> easy to use. Additionally, this feature is only a small change to the
> existing streams API that developers are used to. An underlying sink which
> doesn't observe the controller.signal will continue to have the existing
> behavior.
>
>
> Debuggability
>
> No special support needed.
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag name
> Requires code in //chrome?False
>
> Tracking bug
>

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-09-02 Thread Chris Harrelson 
On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju  wrote:

>
>
> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell 
> wrote:
>
>> Incremental features often benefit from TAG guidance. I'd feel better if
>> this intent at least cited prior TAG reviews in this area or filed an FYI
>> (with potential for TAG to request full review).
>>
>> If it was covered in a previous review of WritableStreams, that would
>> also be good to know.
>>
>
> This feature wasn't covered in a previous review of WritableStreams, so I
> have filed a new TAG review:
> https://github.com/w3ctag/design-reviews/issues/672
>
>
>>
>> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju 
>>> wrote:
>>>
 Contact emailsnidhij...@chromium.org, ri...@chromium.org,
 yhir...@chromium.org

 Explainer
 https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md


>>>

 Specification
 https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal

 Summary

 The streams APIs provide ubiquitous, interoperable primitives for
 creating, composing, and consuming streams of data. This change permits an
 underlying sink to rapidly abort an ongoing write or close when requested
 by the writer.


 Previously, when writer.abort() was called, a long-running write would
 still have to continue to completion before the stream could be aborted.
 With this change, the write can be aborted immediately.

>>>
>>> Am I correct in assuming that the stream developer would have to change
>>> their code in order for that to happen, and if they won't, the current
>>> behavior won't change?
>>>
>>
> Yes, that's correct.
>
>
>>>
 In addition to being exposed to streams authored in JavaScript, this
 facility will also be used by platform-provided streams such as
 WebTransport.

 Blink componentBlink>Network>StreamsAPI
 

 TAG reviewNot needed as this is an incremental improvement to an
 existing feature.

 TAG review statusNot applicable

 Risks
 Interoperability and Compatibility

 Low risk because streams has already been standardised for a long time
 (since around 2014). Other browsers have implemented other parts of the
 standard, and they will most likely also adapt this feature as well soon.

 Gecko: Positive (
 https://github.com/whatwg/streams/pull/1132#issuecomment-867114529
 )
 Mozilla is supportive of Streams but has not yet shipped WritableStream. It
 is expected that they will include this feature when they do. They have
 also expressed interest in implementing WebTransport, and therefore are
 supportive of this feature.

>>>
>>> While such comments don't typically count as a position, combining them
>>> with https://github.com/mozilla/standards-positions/issues/167 seems
>>> reasonable, given the size of this change.
>>>
>>
That said, could you comment on issue 167 giving at least an FYI that this
intent is happening?


>
>>>

 WebKit: No signal

>>>
>>> Have you reached out? https://bit.ly/blink-signals
>>>
>>
> I have requested for WebKit's position here:
> https://lists.webkit.org/pipermail/webkit-dev/2021-September/031977.html
>
>
>>
>>>

 Web developers: No signals

>>>
>>> Have you reached out? https://goo.gle/developer-signals
>>>
>>
> Mattias Buelens has shown positive support here:
> https://github.com/whatwg/streams/issues/1015#issuecomment-531188273
> 
>
>
>>
>>>

 Ergonomics

 A lot of design efforts have been made into making the streams API easy
 to use. Additionally, this feature is only a small change to the existing
 streams API that developers are used to. An underlying sink which doesn't
 observe the controller.signal will continue to have the existing behavior.


 Debuggability

 No special support needed.

 Is this feature fully tested by web-platform-tests
 
 ?Yes

 Flag name
 Requires code in //chrome?False

 Tracking bug
 https://bugs.chromium.org/p/chromium/issues/detail?id=1215992

 Patch
 https://chromium-review.googlesource.com/c/chromium/src/+/3127824

 Estimated milestonesM95

 Link to entry on the Chrome Platform Status
 https://chromestatus.com/feature/5698931422920704

 This intent message was generated by Chrome Platform Status
 .

 --
 You received this message because you are subscribed to the Google
 Groups "blink-dev" group.

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-09-01 Thread Yutaka Hirano 
On Thu, Sep 2, 2021 at 12:22 PM Nidhi Jaju  wrote:

>
>
> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell 
> wrote:
>
>> Incremental features often benefit from TAG guidance. I'd feel better if
>> this intent at least cited prior TAG reviews in this area or filed an FYI
>> (with potential for TAG to request full review).
>>
>> If it was covered in a previous review of WritableStreams, that would
>> also be good to know.
>>
>
> This feature wasn't covered in a previous review of WritableStreams, so I
> have filed a new TAG review:
> https://github.com/w3ctag/design-reviews/issues/672
>
>
>>
>> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju 
>>> wrote:
>>>
 Contact emailsnidhij...@chromium.org, ri...@chromium.org,
 yhir...@chromium.org

 Explainer
 https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md


>>>

 Specification
 https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal

 Summary

 The streams APIs provide ubiquitous, interoperable primitives for
 creating, composing, and consuming streams of data. This change permits an
 underlying sink to rapidly abort an ongoing write or close when requested
 by the writer.


 Previously, when writer.abort() was called, a long-running write would
 still have to continue to completion before the stream could be aborted.
 With this change, the write can be aborted immediately.

>>>
>>> Am I correct in assuming that the stream developer would have to change
>>> their code in order for that to happen, and if they won't, the current
>>> behavior won't change?
>>>
>>
> Yes, that's correct.
>
>
>>>
 In addition to being exposed to streams authored in JavaScript, this
 facility will also be used by platform-provided streams such as
 WebTransport.

 Blink componentBlink>Network>StreamsAPI
 

 TAG reviewNot needed as this is an incremental improvement to an
 existing feature.

 TAG review statusNot applicable

 Risks
 Interoperability and Compatibility

 Low risk because streams has already been standardised for a long time
 (since around 2014). Other browsers have implemented other parts of the
 standard, and they will most likely also adapt this feature as well soon.

 Gecko: Positive (
 https://github.com/whatwg/streams/pull/1132#issuecomment-867114529
 )
 Mozilla is supportive of Streams but has not yet shipped WritableStream. It
 is expected that they will include this feature when they do. They have
 also expressed interest in implementing WebTransport, and therefore are
 supportive of this feature.

>>>
>>> While such comments don't typically count as a position, combining them
>>> with https://github.com/mozilla/standards-positions/issues/167 seems
>>> reasonable, given the size of this change.
>>>
>>>

 WebKit: No signal

>>>
>>> Have you reached out? https://bit.ly/blink-signals
>>>
>>
> I have requested for WebKit's position here:
> https://lists.webkit.org/pipermail/webkit-dev/2021-September/031977.html
>
>
>>
>>>

 Web developers: No signals

>>>
>>> Have you reached out? https://goo.gle/developer-signals
>>>
>>
> Mattias Buelens has shown positive support here:
> https://github.com/whatwg/streams/issues/1015#issuecomment-531188273
> 
>
>

Please also note that, while we believe the mechanism can be useful for
some web developers, our main motivation at this point is WebTransport (#260
, #295
).


>
>>>

 Ergonomics

 A lot of design efforts have been made into making the streams API easy
 to use. Additionally, this feature is only a small change to the existing
 streams API that developers are used to. An underlying sink which doesn't
 observe the controller.signal will continue to have the existing behavior.


 Debuggability

 No special support needed.

 Is this feature fully tested by web-platform-tests
 
 ?Yes

 Flag name
 Requires code in //chrome?False

 Tracking bug
 https://bugs.chromium.org/p/chromium/issues/detail?id=1215992

 Patch
 https://chromium-review.googlesource.com/c/chromium/src/+/3127824

 Estimated milestonesM95

 Link to entry on the Chrome Platform Status
 https://chromestatus.com/feature/5698931422920704

 This intent message was generated by Chrome Platform Status

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-09-01 Thread Nidhi Jaju 
On Wed, Sep 1, 2021 at 10:54 PM Alex Russell 
wrote:

> Incremental features often benefit from TAG guidance. I'd feel better if
> this intent at least cited prior TAG reviews in this area or filed an FYI
> (with potential for TAG to request full review).
>
> If it was covered in a previous review of WritableStreams, that would also
> be good to know.
>

This feature wasn't covered in a previous review of WritableStreams, so I
have filed a new TAG review:
https://github.com/w3ctag/design-reviews/issues/672


>
> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss  wrote:
>
>>
>>
>> On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju 
>> wrote:
>>
>>> Contact emailsnidhij...@chromium.org, ri...@chromium.org,
>>> yhir...@chromium.org
>>>
>>> Explainer
>>> https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
>>>
>>>
>>
>>>
>>> Specification
>>> https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal
>>>
>>> Summary
>>>
>>> The streams APIs provide ubiquitous, interoperable primitives for
>>> creating, composing, and consuming streams of data. This change permits an
>>> underlying sink to rapidly abort an ongoing write or close when requested
>>> by the writer.
>>>
>>>
>>> Previously, when writer.abort() was called, a long-running write would
>>> still have to continue to completion before the stream could be aborted.
>>> With this change, the write can be aborted immediately.
>>>
>>
>> Am I correct in assuming that the stream developer would have to change
>> their code in order for that to happen, and if they won't, the current
>> behavior won't change?
>>
>
Yes, that's correct.


>>
>>> In addition to being exposed to streams authored in JavaScript, this
>>> facility will also be used by platform-provided streams such as
>>> WebTransport.
>>>
>>> Blink componentBlink>Network>StreamsAPI
>>> 
>>>
>>> TAG reviewNot needed as this is an incremental improvement to an
>>> existing feature.
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Low risk because streams has already been standardised for a long time
>>> (since around 2014). Other browsers have implemented other parts of the
>>> standard, and they will most likely also adapt this feature as well soon.
>>>
>>> Gecko: Positive (
>>> https://github.com/whatwg/streams/pull/1132#issuecomment-867114529
>>> )
>>> Mozilla is supportive of Streams but has not yet shipped WritableStream. It
>>> is expected that they will include this feature when they do. They have
>>> also expressed interest in implementing WebTransport, and therefore are
>>> supportive of this feature.
>>>
>>
>> While such comments don't typically count as a position, combining them
>> with https://github.com/mozilla/standards-positions/issues/167 seems
>> reasonable, given the size of this change.
>>
>>
>>>
>>> WebKit: No signal
>>>
>>
>> Have you reached out? https://bit.ly/blink-signals
>>
>
I have requested for WebKit's position here:
https://lists.webkit.org/pipermail/webkit-dev/2021-September/031977.html


>
>>
>>>
>>> Web developers: No signals
>>>
>>
>> Have you reached out? https://goo.gle/developer-signals
>>
>
Mattias Buelens has shown positive support here:
https://github.com/whatwg/streams/issues/1015#issuecomment-531188273



>
>>
>>>
>>> Ergonomics
>>>
>>> A lot of design efforts have been made into making the streams API easy
>>> to use. Additionally, this feature is only a small change to the existing
>>> streams API that developers are used to. An underlying sink which doesn't
>>> observe the controller.signal will continue to have the existing behavior.
>>>
>>>
>>> Debuggability
>>>
>>> No special support needed.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>>
>>> Flag name
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1215992
>>>
>>> Patch
>>> https://chromium-review.googlesource.com/c/chromium/src/+/3127824
>>>
>>> Estimated milestonesM95
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5698931422920704
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>> --
>>> 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/CAMZNYAP-Of819oOp4yq8vRdzx78UUCPj9YKJqx4ZwLj_YsN%3D-Q%40mail.gmail.com
>>>

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-09-01 Thread Alex Russell 
Incremental features often benefit from TAG guidance. I'd feel better if
this intent at least cited prior TAG reviews in this area or filed an FYI
(with potential for TAG to request full review).

If it was covered in a previous review of WritableStreams, that would also
be good to know.

On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss  wrote:

>
>
> On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju  wrote:
>
>> Contact emailsnidhij...@chromium.org, ri...@chromium.org,
>> yhir...@chromium.org
>>
>> Explainer
>> https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
>>
>>
>
>>
>> Specification
>> https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal
>>
>> Summary
>>
>> The streams APIs provide ubiquitous, interoperable primitives for
>> creating, composing, and consuming streams of data. This change permits an
>> underlying sink to rapidly abort an ongoing write or close when requested
>> by the writer.
>>
>>
>> Previously, when writer.abort() was called, a long-running write would
>> still have to continue to completion before the stream could be aborted.
>> With this change, the write can be aborted immediately.
>>
>
> Am I correct in assuming that the stream developer would have to change
> their code in order for that to happen, and if they won't, the current
> behavior won't change?
>
>
>> In addition to being exposed to streams authored in JavaScript, this
>> facility will also be used by platform-provided streams such as
>> WebTransport.
>>
>> Blink componentBlink>Network>StreamsAPI
>> 
>>
>> TAG reviewNot needed as this is an incremental improvement to an
>> existing feature.
>>
>> TAG review statusNot applicable
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Low risk because streams has already been standardised for a long time
>> (since around 2014). Other browsers have implemented other parts of the
>> standard, and they will most likely also adapt this feature as well soon.
>>
>> Gecko: Positive (
>> https://github.com/whatwg/streams/pull/1132#issuecomment-867114529
>> )
>> Mozilla is supportive of Streams but has not yet shipped WritableStream. It
>> is expected that they will include this feature when they do. They have
>> also expressed interest in implementing WebTransport, and therefore are
>> supportive of this feature.
>>
>
> While such comments don't typically count as a position, combining them
> with https://github.com/mozilla/standards-positions/issues/167 seems
> reasonable, given the size of this change.
>
>
>>
>> WebKit: No signal
>>
>
> Have you reached out? https://bit.ly/blink-signals
>
>
>>
>> Web developers: No signals
>>
>
> Have you reached out? https://goo.gle/developer-signals
>
>
>>
>> Ergonomics
>>
>> A lot of design efforts have been made into making the streams API easy
>> to use. Additionally, this feature is only a small change to the existing
>> streams API that developers are used to. An underlying sink which doesn't
>> observe the controller.signal will continue to have the existing behavior.
>>
>>
>> Debuggability
>>
>> No special support needed.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>> Flag name
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1215992
>>
>> Patch
>> https://chromium-review.googlesource.com/c/chromium/src/+/3127824
>>
>> Estimated milestonesM95
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5698931422920704
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> 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/CAMZNYAP-Of819oOp4yq8vRdzx78UUCPj9YKJqx4ZwLj_YsN%3D-Q%40mail.gmail.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/CAL5BFfXWMCdEAA51FQ6tJyG8CfuU_oOb-x0-mmBp5qFkDpFP8A%40mail.gmail.com
>

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-09-01 Thread Yoav Weiss 
On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju  wrote:

> Contact emailsnidhij...@chromium.org, ri...@chromium.org,
> yhir...@chromium.org
>
> Explainer
> https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
>
>

>
> Specification
> https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal
>
> Summary
>
> The streams APIs provide ubiquitous, interoperable primitives for
> creating, composing, and consuming streams of data. This change permits an
> underlying sink to rapidly abort an ongoing write or close when requested
> by the writer.
>
>
> Previously, when writer.abort() was called, a long-running write would
> still have to continue to completion before the stream could be aborted.
> With this change, the write can be aborted immediately.
>

Am I correct in assuming that the stream developer would have to change
their code in order for that to happen, and if they won't, the current
behavior won't change?


> In addition to being exposed to streams authored in JavaScript, this
> facility will also be used by platform-provided streams such as
> WebTransport.
>
> Blink componentBlink>Network>StreamsAPI
> 
>
> TAG reviewNot needed as this is an incremental improvement to an existing
> feature.
>
> TAG review statusNot applicable
>
> Risks
> Interoperability and Compatibility
>
> Low risk because streams has already been standardised for a long time
> (since around 2014). Other browsers have implemented other parts of the
> standard, and they will most likely also adapt this feature as well soon.
>
> Gecko: Positive (
> https://github.com/whatwg/streams/pull/1132#issuecomment-867114529
> )
> Mozilla is supportive of Streams but has not yet shipped WritableStream. It
> is expected that they will include this feature when they do. They have
> also expressed interest in implementing WebTransport, and therefore are
> supportive of this feature.
>

While such comments don't typically count as a position, combining them
with https://github.com/mozilla/standards-positions/issues/167 seems
reasonable, given the size of this change.


>
> WebKit: No signal
>

Have you reached out? https://bit.ly/blink-signals


>
> Web developers: No signals
>

Have you reached out? https://goo.gle/developer-signals


>
> Ergonomics
>
> A lot of design efforts have been made into making the streams API easy to
> use. Additionally, this feature is only a small change to the existing
> streams API that developers are used to. An underlying sink which doesn't
> observe the controller.signal will continue to have the existing behavior.
>
>
> Debuggability
>
> No special support needed.
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag name
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1215992
>
> Patch
> https://chromium-review.googlesource.com/c/chromium/src/+/3127824
>
> Estimated milestonesM95
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5698931422920704
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> 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/CAMZNYAP-Of819oOp4yq8vRdzx78UUCPj9YKJqx4ZwLj_YsN%3D-Q%40mail.gmail.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/CAL5BFfXWMCdEAA51FQ6tJyG8CfuU_oOb-x0-mmBp5qFkDpFP8A%40mail.gmail.com.

[blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-08-31 Thread Nidhi Jaju 
Contact emailsnidhij...@chromium.org, ri...@chromium.org,
yhir...@chromium.org

Explainer
https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md

Specification
https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal

Summary

The streams APIs provide ubiquitous, interoperable primitives for creating,
composing, and consuming streams of data. This change permits an underlying
sink to rapidly abort an ongoing write or close when requested by the
writer.


Previously, when writer.abort() was called, a long-running write would
still have to continue to completion before the stream could be aborted.
With this change, the write can be aborted immediately. In addition to
being exposed to streams authored in JavaScript, this facility will also be
used by platform-provided streams such as WebTransport.

Blink componentBlink>Network>StreamsAPI


TAG reviewNot needed as this is an incremental improvement to an existing
feature.

TAG review statusNot applicable

Risks
Interoperability and Compatibility

Low risk because streams has already been standardised for a long time
(since around 2014). Other browsers have implemented other parts of the
standard, and they will most likely also adapt this feature as well soon.

Gecko: Positive (
https://github.com/whatwg/streams/pull/1132#issuecomment-867114529
)
Mozilla is supportive of Streams but has not yet shipped WritableStream. It
is expected that they will include this feature when they do. They have
also expressed interest in implementing WebTransport, and therefore are
supportive of this feature.

WebKit: No signal

Web developers: No signals

Ergonomics

A lot of design efforts have been made into making the streams API easy to
use. Additionally, this feature is only a small change to the existing
streams API that developers are used to. An underlying sink which doesn't
observe the controller.signal will continue to have the existing behavior.


Debuggability

No special support needed.

Is this feature fully tested by web-platform-tests

?Yes

Flag name
Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1215992

Patch
https://chromium-review.googlesource.com/c/chromium/src/+/3127824

Estimated milestonesM95

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5698931422920704

This intent message was generated by Chrome Platform Status
.

-- 
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/CAMZNYAP-Of819oOp4yq8vRdzx78UUCPj9YKJqx4ZwLj_YsN%3D-Q%40mail.gmail.com.