Re: [whatwg] why does fetch() specify response body processing frequency?
On Wed, Jul 23, 2014 at 5:42 AM, Takeshi Yoshino wrote: > "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 Yeah, this is correct, although maybe not what we want. Originally it said every 50ms or for every byte received, whichever is least frequent. Now we acknowledge traffic happens in chunks, perhaps we should make it every 50ms or for each push, whichever is most frequent. -- http://annevankesteren.nl/
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 (陈智昌) 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" 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 (陈智昌) < >> willc...@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. >>> >> >>
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" 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 (陈智昌) > 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. >> > >
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 (陈智昌) 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. >
[whatwg] why does fetch() specify response body processing frequency?
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.
