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

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 00:53:32 UTC