[whatwg] Fetch: networking tasks

[Anne van Kesteren]

On Mon, Mar 4, 2013 at 8:14 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 4 Mar 2013, Anne van Kesteren wrote:
>> 1) How does HTML distinguish for which fetch the tasks are queued?
>
> How do you mean?

What I meant was that when loading a page, various APIs will start
invoking fetch. That in turn will queue network tasks for "traffic".
However, there's nothing really that ties these together in a coherent
story.


>> 2) How do we deal with tasks for uploading data? Currently fetch only
>> deals with processing incoming data, not outgoing.
>
> Why would you need tasks for uploading?

XMLHttpRequest dispatches events while data is being transmitted to the server.


>> In both these cases, how do we either allow the caller to filter or
>> filter for caller?
>
> Not sure what you mean.

Some of the fetching that happens should not be exposed (preflight
request, redirects). It seems cleanest to do this at the fetching
layer itself and not make it easy for consumers of the fetch algorithm
to shoot themselves in the foot.


>> Caller APIs are generally not interested in redirects, e.g. progress
>> events are for the response entity body, not any number of redirects
>> that preceded receiving that. Upload progress events are only ever
>> transmitted after a CORS preflight completed.
>
> Doesn't the current prose already handle all this?

Maybe? It's not entirely clear to me.


>> Also, is the networking task source exclusively used for fetch? Should
>> we rename it then (harhar)?
>
> It's used by various things, seach for "is the networking task source" in
> the HTML spec. e.g. "update the session history with the new page" uses
> it. Basically, anything that needs to be ordered relative to network
> activity rather than DOM activity.

Well, WebSocket appears to be using its own task source.


Olli and I came up with another case we're currently not covering.
XMLHttpRequest exposes of a response when all headers are received,
when a byte of the body has been transmitted or when no body is
transmitted, and when the response is fully transmitted. It is
important that a) these are all separate tasks on the networking task
source as via methods that spin the event loop such as showModalDialog
the exact number of tasks becomes detectable and would possibly give
weird results (e.g. instead of HEADERS_RECEIVED LOADING DONE you might
get HEADERS_RECEIVED DONE LOADING if HEADERS_RECEIVED and LOADING
happen in the same task and showModelDialog is invoked during the
first callback). XMLHttpRequest needs to be able to hook into these
tasks too in some fashion so they should be labeled in some way.


-- 
http://annevankesteren.nl/