- From: Andrea Giammarchi <andrea.giammarchi@gmail.com>
- Date: Fri, 27 Feb 2015 07:43:09 +0000
- To: Kevin Smith <zenparsing@gmail.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
- Message-ID: <CADA77mieL-6pedKgXOGH35BYWu99gcLST-BK5Kbo09iUCVHM+w@mail.gmail.com>
AFAIK bluebird did: https://github.com/petkaantonov/bluebird/blob/master/API.md#cancelerror-reason---promise 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! ....right? On Fri, Feb 27, 2015 at 7:31 AM, Kevin Smith <zenparsing@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@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: >> >> https://github.com/slightlyoff/ServiceWorker/issues/625 >> >> 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 >> forever. >> >> >> -- >> https://annevankesteren.nl/ >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
Received on Friday, 27 February 2015 07:43:37 UTC