andrea.giammarchi at gmail.com
Thu Feb 26 23:43:09 PST 2015
AFAIK bluebird did:
But I agree once you've made Promises more complex than events ( xhr in
this case ) nobody wins :-/
Although, specially for fetch or anything network related, there **must**
be a way to bloody cancel that!
On Fri, Feb 27, 2015 at 7:31 AM, Kevin Smith <zenparsing at gmail.com> wrote:
> The discussion on that github issue surrounding promise subclassing makes
> my head spin, especially when it comes to working out how cancelation is
> supposed to flow through a graph of promise dependencies. We should be
> wary of adding complexity to the core.
> The simple way to view the situation is to say that promises are simply
> transparent containers for asynchronous values. Control capabilities should
> therefore be represented by a separate abstraction. This will help keep
> complexity at the edges.
> Has any library experimented with the cancelation token approach yet?
> On Feb 27, 2015 1:46 AM, "Anne van Kesteren" <annevk at annevk.nl> wrote:
>> As a heads up, there's some debate around the fetch() API how exactly
>> request termination should work and how that affects promises:
>> The WebRTC WG has also been discussing canceling in the context of
>> terminating a request for permission from the user. I think they
>> decided to postpone for now until there's a bit more progress on what
>> cancelable promises means, but I would not expect everyone to wait
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss