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

I keep coming back to this as it's such a fundamental issue:

1. `fetch()` should not go in parallel itself, that's just wrong: #1163.
2. In principle most of fetch is designed to be invoked from the main thread as global state is available there. For those wanting to invoke fetch while in parallel, more work needs to be done to adequately capture that global state at the right point in time. I do think we should make that work, to be clear, and policy containers will hopefully help with this.
3. I do think it makes sense for the fetch algorithm to explicitly take these "callbacks" as parameters. Currently we have five callbacks listed at https://fetch.spec.whatwg.org/#process-request-body. Apart from making these explicit parameters I don't think there is much that needs to change here for main thread usage of fetch.
   1. We need to have an easy way to get at the bytes of a response body. (We could just expose a specification-only byte sequence on responses. We could allow specifications to treat `ReadableStream` of responses for which end-of-file has run as equivalent to a byte sequence (perhaps with some magic conversion algorithm that does the relevant asserts). Thoughts appreciated.)
4. I don't have a good solution for "in parallel" callers, especially those that want to process a response incrementally. Perhaps a return value is still a good fit here and the API would be that you "wait" for things to become non-null.
5. We might also want a return value for main thread callers that is equivalent to the above except that it would be filled in from tasks.
6. The return value could also expose terminate, soundly coupling it to the fetch.

@jakearchibald @domenic @jyasskin @ricea @gterzian thoughts?

-- 
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-775170346