Re: [whatwg/fetch] Fetch termination API "meeting" (#455)

My feedback on [the meeting notes](https://github.com/whatwg/fetch/issues/455#issuecomment-274869169):

- Everything in "Decided" sounds right, though re: "We're going to move forward with the revealing-function pattern." - any thoughts on also allowing FetchControllers to be preconstructed, [in the compatible fashion I described in my FetchController-spec](https://github.com/stuartpb/FetchController-spec)?
- "What does cancellation looks like?" - what you described there [is what I've been working with](https://github.com/stuartpb/FetchController-spec#fetchcontrollerabort).
- "What's the link between the controller and observer?" - in [the spec I wrote](https://github.com/stuartpb/FetchController-spec), a FetchObserver is effectively independent of a FetchController (beyond the fact that it is attached to observing the same fetch as the controller controls). A FetchController always contains a FetchObserver, because it shouldn't be possible to end up in a situation where you can *act* on a fetch whose status you can't read. Note that, as written, a FetchObserver doesn't "belong" to a FetchController so much as it is *intrinsically associated with it*, due to the dynamics of how a Fetch may be dispatched 
(there's no way to start a Fetch with a Controller and an Observer that isn't the one attached to that Controller).
- "The observable should be async, so it can exist in a different thread to the fetch." It's already got an `addEventListener`, and I think that's quite async enough. If this statement means to assert that multi-threading should imply *all mutable properties* to be only obtainable through asynchronous accessors, I will state now that I *do not concur* with that assertion, and can expand on the reasons in a separate issue.
- "It should be reasonably easy to control multiple fetches in the same way." - Keeping a collection of FetchControllers and performing operations in a `coll.forEach(ctl=>{/*...*/})` seems perfectly reasonable to me.
- Same goes for affecting a fetch as a result of something happening in an observed fetch - `observe.addEventListener('abort',e=>coll.forEach(ctl=>ctl.abort()))` seems fine to me.
- "Aborting an already-complete request shouldn't produce an error, it should be a no-op, but there should be some way to confirm that something was actually aborted." - I *was* thinking this should be an error, but I'm coming around to the argument here that it should be fire-and-report-if-it-did-anything, since we can't well take events out once another thread's put them in the pipe. I'll expand on this in #448.

-- 
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/455#issuecomment-275229838