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

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 Tuesday, 22 July 2014 23:42:48 UTC