W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Future cancellation

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 30 Apr 2013 19:56:40 -0700
Message-ID: <CA+c2ei8g6ZVKaJr6BRe07NZi62=DODeO6V9nZmuZaOk=fRPmHg@mail.gmail.com>
To: Ron Buckton <rbuckton@chronicles.org>
Cc: es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
On Tue, Apr 30, 2013 at 7:37 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> Then there's of course the issue of what we should do with APIs that
> combine several Futures into a single one. Like Future.every() etc.
>
> Similarly, there's also the issue of what to do with chaining.
>
> I'm tempted to say that if you create combined or dependent Futures,
> you still only have the ability to cancel them through the original
> CancelableFuture.
>
> Like others have pointed out here, we need to keep "operations"
> separate from "delivering results". Combined and dependent Futures are
> combining the delivering of results, but they don't combine the
> operations.

There are actually some very big similarities here with
ProgressFuture. There too we are facing the question of what to do if
multiple Futures, some of which are ProgressFutures, are combined
using Future.every, or what to do if a Future is chained after a
ProgressFuture.

It isn't actually surprising that the same issues arise.
ProgressFuture basically delivers progress about an "operation" rather
than a "result".

My gut instinct is still the same. Combining results using dependent
or combined Futures is great. However trying to combine operations
seems like a lot of complexity and easily a source of confusion.

/ Jonas
Received on Wednesday, 1 May 2013 02:57:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC