Re: [fetch] Aborting a fetch (#27)

Just to be clear @getify, I am not talking here about "concepts" in general, but rather about "implementation concepts" and not "implementation details of those concepts". Main goal of this is to stop flying around few differing concepts arguing with implementations details, many heuristics, etc. We need to choose something already here, otherwise it will never end.

So, let's me comment your items, but please, do not go into "I believe this is concept, but this is not".  Let's agree on things which easy to decide (some high-level concept over upcoming implementation of them).

> fetch(..) should be cancelable in some way, and that cancels the request and any response "observers".

This is exactly that thing about I am talking. We flying around few concepts of should it be promise or not, chainable or not, blah or not-a-blah. We need to decide and then go on.

> If the fetch(..) action is canceled, the entire down-stream chain of its "observers" must be canceled/aborted/rejected/etc, not just the first level. Ideally this cancelation would be observable down-stream (either as a rejection or as a third state).

This is implementation detail about how it should be chainable. I am ask about agreement what it should "chainable", implementations things "how" will follow later.

> The cancelation capability should be something that go wherever the "obvservable"-for-response can go (whether that be as separate values, composed in a single object, or combined into promises).

Cannot understand this, but please do not continue.

> Should make sense, and be equally effective, with async..await and any other (future) language mechanism that either explicitly or implicitly creates promises to represent the completion of a task.

I believe this is same as I wrote in my last item, but just in other words. I can live with this sentence if this makes you more comfortable.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/27#issuecomment-87832123