Re: [whatwg/fetch] Aborting a fetch: The Next Generation (#447)

A salient idea I just had on why the `control` argument to `fetch` should take a pre-constructed object if the value isn't a callback to reveal construction through: this would allow for the extension of *native-implementation* fetch-controlling objects.

For instance, [as  Anne noted](https://github.com/whatwg/fetch/issues/448#issuecomment-275360312) in #448, a fetch that intends to propagate the status from an upstream fetch in a Service Worker would need to have that propogation performed *via JS-thread mediation*, introducing an unnecessary amount of message-passing overhead. If the `observe` argument is specced to accept externally-constructed objects, there could then be some alternative object specified down the line that signals that control is derived as such, allowing the propagation to take place *without touching the JS thread*, with something like `new FetchFollowingController(evt.fetchReporter)` (this also addresses the question of making it easier to follow an existing fetch's events, as raised in the meeting notes).

-- 
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/447#issuecomment-276586154