- From: Domenic Denicola <notifications@github.com>
- Date: Wed, 10 Feb 2021 12:59:32 -0800
- To: whatwg/xhr <xhr@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/xhr/pull/311/review/588040137@github.com>
@domenic approved this pull request.
This looks reasonable, but the dance of having processResponse set a boolean and then waiting for the boolean seems like it'd be painful if it was repeated for every in-parallel fetch in the HTML spec. I'd kind of prefer having Fetch do that for us still...
> @@ -851,7 +836,8 @@ return <a>this</a>'s <a>cross-origin credentials</a>.
</ol>
<!-- upload complete flag can never be set here I hope -->
- <p>To <a>process response</a> for <var>response</var>, run these steps:
+ <li>
+ <p>Let <var>processResponse</var>, given a <var>response</var>, be these steps:
Step 2 below has a typo "fo" instead of "for"
Also, most steps after step 1 seem to use "this's response", but step 2 uses "response".
> @@ -851,7 +836,8 @@ return <a>this</a>'s <a>cross-origin credentials</a>.
</ol>
<!-- upload complete flag can never be set here I hope -->
- <p>To <a>process response</a> for <var>response</var>, run these steps:
+ <li>
+ <p>Let <var>processResponse</var>, given a <var>response</var>, be these steps:
Some steps use "terminate these steps" to bail, others use "return". Probably "abort these steps" is most common and best?
> <li>
- <p>Let <var>response</var> be the result of
- <a for=/>fetching</a> <var>req</var>.
+ <p>Let <var>processResponse</var>, given a <var>fetchResponse</var>, be these steps:
+
+ <ol>
+ <li><p>Set <var>response</var> to <var>fetchResponse</var>.
+
+ <li><p>Set <var>doesNotBlockTask</var> to true.
+ </ol>
+
+ <li><p><a for=/>Fetch</a> <var>req</var> with <a for=fetch><i>processResponse</i></a>
+ set to <var>processResponse</var> and <a for=fetch><i>useParallelQueue</i></a> set to true.
+
+ <li><p>Wait until either <var>doesNotBlockTask</var> is true or <a>this</a>'s <a>timeout</a> is
This isn't so bad.
I wonder if it should use https://html.spec.whatwg.org/#pause ?
> <li>
- <p>Let <var>response</var> be the result of
- <a for=/>fetching</a> <var>req</var>.
+ <p>Let <var>processResponse</var>, given a <var>fetchResponse</var>, be these steps:
+
+ <ol>
+ <li><p>Set <var>response</var> to <var>fetchResponse</var>.
+
+ <li><p>Set <var>doesNotBlockTask</var> to true.
+ </ol>
+
+ <li><p><a for=/>Fetch</a> <var>req</var> with <a for=fetch><i>processResponse</i></a>
+ set to <var>processResponse</var> and <a for=fetch><i>useParallelQueue</i></a> set to true.
+
+ <li><p>Wait until either <var>doesNotBlockTask</var> is true or <a>this</a>'s <a>timeout</a> is
+ not 0 and <a>this</a>'s <a>timeout</a> milliseconds have passed since now.
I'd prefer saving "now" in a previous step. Although the intention is clear, as written one could interpret this as never happening.
> @@ -930,13 +933,27 @@ return <a>this</a>'s <a>cross-origin credentials</a>.
is not <a>allowed to use</a> the "<code><a>sync-xhr</a></code>" feature, then run
<a>handle response end-of-body</a> for <a>this</a> and a <a>network error</a>, and then return.
+ <li><p>Let <var>response</var> be a <a for=/>network error</a>.
+
+ <li><p>Let <var>doesNotBlockTask</var> be false.
I find this variable name pretty confusing. Maybe _processedResponse_?
> @@ -825,7 +809,8 @@ return <a>this</a>'s <a>cross-origin credentials</a>.
<p class=note>These steps are only invoked when new bytes are transmitted.
- <p>To <a>process request end-of-body</a> for <var>request</var>, run these steps:
+ <li>
+ <p>Let <var>processRequestEndOfBody</var>, given a <var>request</var>, be these steps:
<ol>
<li><p>Set <a>this</a>'s <a>upload complete flag</a>.
I've been treating spec steps as "arrow functions" which close over "this". "this" is unique for the entire definition of the method, so this doesn't seem likely to cause confusion.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/xhr/pull/311#pullrequestreview-588040137
Received on Wednesday, 10 February 2021 20:59:46 UTC