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

> My concern with the more benign ignore semantics you mention is that it I see little technical difference - the lack of a way to consume one of these promises without implicit interest is still a problem

Consuming a promise is very explicit interest in its result.

>  I see merely a recasting of expectations, with little guidance for folks looking for the cancellation hammer.

The thing is - when we looked at actual real use cases no one is really looking for a "cancellation hammer". All the use cases we looked at (for example XHRs) work beautifully with disinterest cancellation semantics. That is - I looked at hundreds of projects w.r.t cancellation and answered over half a thousand promise question on Stack Overflow and have never seen someone who needed a "cancellation hammer" or even wanted one. Abort semantics are very frowned upon in other languages and systems too. Even in other primitives (like observables) it is _highly_ discouraged to have unsubscribe with multiple subscribers without refcounting. 

> You make a distinction between single and multiple subscriber promise-use as if they're two ways of working that users can choose between.

Users don't need to care, cancellation would "just work". 

> they cannot guarantee that the net promise-chain is free of multiple subscribers (now or in future version of libraries)

Of course, probably the vast majority of libraries returning promises wouldn't even support cancellation - the nice thing with this model is that with disinterest semantics that can be incrementally added later on, so people can start writing cancellation-aware code today and it'll be optimized later on. 

And of course, that's a _different_ model from abort semantics - which can be added anyway through a token-based approached (discussion on https://esdiscuss.org/topic/promises-as-cancelation-tokens )

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

Received on Thursday, 28 January 2016 21:10:57 UTC