- From: Anne van Kesteren <notifications@github.com>
- Date: Mon, 08 Jun 2020 00:47:16 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/536/640429370@github.com>
It's still not entirely obvious to me what abstraction would work well here. Some thoughts: * It's useful that fetch can be invoked from the main thread as a bunch of state (e.g., a mutable CSP policy) is passed in that doesn't really work from "in parallel" land (because it can be mutated). Perhaps though that is something that needs sorting out so that such state can be copied at the right time and passed across the in parallel boundary with ease. * If we want to support full duplex the model where you go in parallel, fetch, and then wait for the response, the body, and the trailers, doesn't work, as you wouldn't be able to send the request body and request trailers at the same time. (No browser supports full duplex though and even with streams nobody seems interested in supporting it. That is, the full request body would have to be transmitted before you start seeing response bytes.) @gterzian the reason to use a parallel queue I guess is to ensure that you do not process the response body before the response headers? It might work I suppose, but it would have to be flushed out a bit to ensure the right information is passed around to be able to queue tasks from there and such. (Tasks need a bit more information these days.) And I guess to support synchronous fetching we could use "Wait" (which we should probably define somewhere) in the main thread that looks for some variable shared with in parallel to flip. -- 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-640429370
Received on Monday, 8 June 2020 07:47:30 UTC