Re: [whatwg] why does fetch() specify response body processing frequency?

+annevk

"process response body" in the XHR spec is only handling errors and firing
a readystatechange event and ProgressEvents. "response" in the XHR spec [1]
is set to the argument "response" of "process response" hook. I think this
"set" means making "response" [1] point to the "response" in the Fetch spec
[2]. As newly received data is pushed by the HTTP fetch in the Fetch spec
side, it'll be available for read from response's body in the XHR spec
side. This doesn't require "process response body" invocation. That's my
understanding.

In the fetch() method spec [3], fetch [4] is called with "process response
body" of no-op. This also means (implies) that "process response body" is
not needed for response's body to get populated, I think.

[1] http://xhr.spec.whatwg.org/#response
[2] http://fetch.spec.whatwg.org/#fetching
[3] http://fetch.spec.whatwg.org/#dom-global-fetch
[4] http://fetch.spec.whatwg.org/#concept-fetch

Takeshi


On Wed, Jul 23, 2014 at 9:53 AM, William Chan (陈智昌) <willchan@chromium.org>
wrote:

> Thanks for the explanation. Does that mean that the current wording is
> suboptimal and should be fixed? I don't think it's advisable to say that
> response body processing in general should have these delays. But maybe I
> just don't fully understand what processing means.
>  On Jul 22, 2014 4:42 PM, "Takeshi Yoshino" <tyoshino@google.com> wrote:
>
>> I think it's from the old XHR spec. Originally this algorithm was
>> introduced in the XHR spec to fire "progress" ProgressEvents. In
>> refactoring of the XHR spec into current XHR spec and Fetch spec, it's
>> placed in the Fetch spec part, and now is referred from the Fetch API spec
>> in the Fetch spec document.
>>
>> http://xhr.spec.whatwg.org/#the-send()-method
>>
>> Takeshi
>>
>>
>> On Wed, Jul 23, 2014 at 6:31 AM, William Chan (陈智昌) <
>> willchan@chromium.org> wrote:
>>
>>> http://fetch.spec.whatwg.org/#fetching says:
>>>
>>> """
>>> Otherwise, if response's body is non-null, run these substeps:
>>>
>>> Every 50ms or whenever response's body's is pushed to, whichever is least
>>> frequent and as long as response has no termination reason and
>>> end-of-file
>>> has not been pushed, queue a task to process response body for response.
>>> """
>>>
>>> Is this some attempt to reduce overhead on response body processing by
>>> processing larger chunks of data fewer times? If so, it seems like this
>>> should be left up to UA discretion and not specified here. This also
>>> disallows using the response body stream as a low latency channel. For
>>> example, if you were fetching video or audio content (like YouTube does
>>> with XHRs), adding an arbitrary 50ms delay seems undesirable. Also, if
>>> you
>>> were running an application layer protocol on top of the request/response
>>> body streams, then the 50 ms delay seems to incur unnecessary latency.
>>>
>>> Sorry if I missed some context around this. If there was previous
>>> discussion on this that I should read, please point it out for me.
>>> Thanks.
>>>
>>
>>

Received on Wednesday, 23 July 2014 03:43:27 UTC