Re: [whatwg/fetch] Odd format for fetch callbacks (#536)

Have you though of defining a [parallel queue](https://html.spec.whatwg.org/multipage/infrastructure.html#parallel-queue), and then instead of queuing tasks, queue steps on the parallel queue, and define that those steps would call into callbacks(still "in-parallel"), such as `process_response`.

So for example the current definition of [`process_response`](https://fetch.spec.whatwg.org/#ref-for-process-response%E2%91%A1) as used in fetch, could be reworded as:

1. If locallyAborted is true, terminate these substeps. (note: this happens fully "in-parallel", with `locallyAborted` being a local variable of the parallel steps).
2. Queue a task using the networking task-source to:
    2.1 /// Add current steps 2 -> 6 here, running inside the queued task. 

Whereas in the background-fetch use case, the callbacks simply operate on the "local" data of the in-parallel algorithm that started the fetch, so there is no need to queue a task(so the spec could simply remove the note to this issue, and it would work "as-is" really). 

One thing worth noting I think is how the "request" is passed around in a callback like `process request body`, where the `transmitted_bytes` is first written to by fetch, and then read by background fetch. I can imagine this could get interesting if bg fetch were to also write some data into request, especially if other specs then also define a `process_request_body` callback. It might be more robust to re-define the callback as "process_request_transmitted_bytes" or something, passing a copy of the `transmitted_bytes` variable to each of the callback invocation? Or maybe this is too concerned with details and we can assume the intent of "broadcasting to callbacks that a certain amount of bytes have been transmitted" via the current `process request body` is clear enough and no-one is going to try to define things in different specs that would expect a different model? 


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/536#issuecomment-639971536