- From: 陈智昌 <willchan@chromium.org>
- Date: Tue, 22 Jul 2014 17:53:07 -0700
- To: Takeshi Yoshino <tyoshino@google.com>
- Cc: whatwg <whatwg@whatwg.org>
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