concavelenz at gmail.com
Fri Feb 27 19:49:14 PST 2015
Closure Library's promise implementation supports "cancel":
A promise is cancelled only if all the "child" promises are also cancelled.
On Thu, Feb 26, 2015 at 11:43 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:
> 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
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss