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

Re: Future cancellation

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 1 May 2013 11:10:45 -0700
Message-ID: <CAAWBYDCR38Fxt1BT0ULHqVPkXC-sFPU+f09MaZ2BJ9GUzaE3dQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: es-discuss <es-discuss@mozilla.org>, Domenic Denicola <domenic@domenicdenicola.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Wed, May 1, 2013 at 9:38 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On May 1, 2013 8:21 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>
>> On Wed, May 1, 2013 at 12:16 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> > However with this approach you get an API which automatically simply
>> > works as an API returning a Future in case you don't need to abort the
>> > operation or display its progress:
>> >
>> > handleResult(doSomeOperation());
>> > or
>> > return doSomeOperation();
>> > or
>> > doSomeOperation().then(val => displayResult(val));
>> >
>> > I.e. if you don't care about the operation part, the API simply works
>> > as any other API which returns a promise. This seems like a very nice
>> > thing. The only "cost" of this API is that it doesn't compose when you
>> > compose the future, but neither does the dispose object in the tuple
>> > approach.
>>
>> The other cost is an inherent capability leak - *unless* you purposely
>> strip it of its cancelability, passing it around to anything else
>> gives the "anything else" the ability to cancel your promise as well.
>> The tuple approach doesn't have this issue - the promise and the
>> canceler/resolver are inherently separated, and you have to purposely
>> hand the canceler/resolver off to other code for it to have any
>> powers.
>
> This is a problem that the current XHR API is suffering from too. Has that
> been a problem in reality?
>
> With XHR you can even affect the values that other consumers are receiving
> by setting .response type. Again, does anyone have examples of when this has
> been a problem?
>
> I feel like attempting to solve this problem will mean that we need to split
> a lot of interfaces into lists of objects, each representing a capability.
> This seems like it will very quickly lead to an unmanageable mess.

I don't think this is a valid slippery-slope argument.  If it were
true, it would show itself more strongly, as us, for example,
splitting up the resolver into two or three different objects for each
of the operations, and maybe the promise into two objects as well for
each of the channels.

In practice, you can split things into capabilities that are
reasonable to group together.  However, a cancellable promise blurs
the line.  Maybe that's not important?  I dunno.

> Wrapping a CancelableFuture in a normal Future seems like an acceptable
> solution which only adds complexity in the much more rare case that someone
> cares about capabilities.

If we knew that chaining a CancelableFuture always returned a normal
Future, then this might be okay - just do
"getCancellableFuture(foo).then()" to get a normal future out.

~TJ
Received on Wednesday, 1 May 2013 18:11:32 UTC

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