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

@benjamingr reading also this (about your previous comment)
> That being said, the desire for promises to support cancellation is well-grounded. If a promise represents a large quantity of work, as it often does, it does not make sense to continue doing that work when there remain no consumers interested in the result. It makes even less sense if the consumer goes on to ask a similar question that will require the same resources, like a database lock or even just time on the CPU. The issue compounds further when the user is fickle and frequently changing its query, as in search-as-you-type interfaces.

But answering your quote:

  * "_One is to introduce a separate cancellation "capability", perhaps passed as an argument_" is exactly what I've proposed, a third argument that, if invoked, will define how to cancel the Promise
  * "_ each task only have one observer (one then call, ever), can be canceled without fear of interference_" is also possible with my proposal, which gives you the ability to have a cancelable Promise but pass around a Promise that is not cancelable so that only "you" can observe and cancel it

My proposal also returns the `cancel` method internally, once defined, giving extra control/power to the Promise creator/owner in case of exposed cancel-ability.

- - - - - - - - - - - - -

To answer now other questions.

  * I believe `Promise.all` and anything that has to deal with a group of Promises should expose `cancel` only if all Promises in the group are cancelable ... I call it shenanigans otherwise. Please note your example is wrong because you are not providing a way to cancel the timeout so your cancelable Promise does nothing except rejeting (the timer will obviously fire but if canceled the Promise cannot be resolved after being rejected)
  * correct for multiple no-ops, I simply followed what happens if you resolve or reject after having already resolved or rejected ... nothing happen (I don't like it but that's how Promises work so far). This makes life easier if you cancel more than once in a chain of cancelables
  * that works exactly same way a reject in the chain works ... there's no possible `.then` after a reject with this proposal, there was a `.then` after `cancel` with the initial one, but that is based on the equivalent of a task `fork` where the previous branch is silently resolved and never executed
  * not sure I understand the question but I can say two things: 1 `var t = setTimeout(res, 100 - i, i);` does the same, no reason to bind, `setTimeout` by standard accepts extra arguments ;-) ... 2 no reason to attach `p.cancel().catch(function(){});` that `catch` ... promises are resolved regardless (or were you trying to prevent the uncaught Promise error?)

Apologies if I haven't answered everything properly ... I'm trying :-)

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