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

this is where I usually ignore all the philosophy ...

> Ideally the API should be designed so that if developers run up against the limitations of fetch, they can easily modify their code to use fetchTask.

so that all pending Promises will have the "OMG mutable" state because the initial request needs to be cancelable.

> If cancellation is a rare edge case ...

It's not. Everything you POST might need to be canceled and once again we all agree fetch was unfortunate choice as XHR replacement but you are suggesting to have duplicated effort and standards because of a very simple and pragmatic and needed `.cancel()` ... so I usually drop the line where all these discussions become simply pragmatically pointless and against the interest of all Web Developers.

Yeah, you want to cancel that request because that's what we've been doing since about ever with XHR ... having XHR and a broken Fetch replacement for XHR so that we can have a fetchTask as other standard that's practically identical to Fetch except the cancelability would be a benefit for **nobody** due time it takes to ship new APIs and all the confusion around this Fetch potentials.

I rather deprecate Fetch if FetchTask is the answer, or follow pragmatic MS approach and bring Streams to XHR so people that don't need to control network requests can use Fetch and all others can live happily ever after with XHR.

It's just sad we are apparently not moving anywhere here ... I start even dropping interest on this matter.


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