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

> "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

This is not what I believe Kris means here. What Kris is talking about here is a token like approach more akin to what @getify suggested - though I only recall this from IRC and I might be mistaken. 

> "_ 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

I don't believe this is what Kris means here either (based on the link further down to kriskowal/gtor) - the issue is that like I believe @jhusain was trying to say you can get weird tree like - cases if the cancellable can be observed by multiple observers and some try to cancel it without the knowledge of the others (what kris calls "interference"). A task would not have this problem simply because it has a single observer (in which case it is cancellable) and if you convert it to a promise you can no longer cancel it. 

I'm not saying I agree with Kris on the above - it's entirely possible that just pushing `fetch` out already with promises that are cancellable (although there might be better theoretical alternatives) is a better pragmatic choice - or the issue might not manifest itself in real code. I do think that the issue presented here should be investigated and problematic cases should be found and discussed which is why I brought Kris's post up. 

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

> 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.

So now `Promise.all` has to be aware of cancellation and cancellable promises? Do we want to overload `.all`? Do we want `CancellablePromise.all` instead or something like that? 

> 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)

Yes - I didn't care about actually doing something useful in cancellation - just the API :)

> 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 makes sense - a second time noop'ing has advantages - so does throwing an exception. I agree that noop is more similar to existing resolve/reject semantics.

> 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 ;-) ...

Old habits die hard :)

>  2 no reason to attach p.cancel().catch(function(){}); that catch ... 

That's there since it suppresses unhandled rejection detection, since the promises are cancelled there are now unhandled rejections in the code which the browser tooling finds up and reports to the dev tools. I was just suppressing that :) 

> promises are resolved regardless (or were you trying to prevent the uncaught Promise error?)

Yeah, should've read the last sentence first. What I meant though - is do you think that more constructs need to be introduced as static promise methods to the library or not in the light of cancellation?

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