W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

Re: [futures] Making ProgressFuture immediate

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 19 Apr 2013 09:49:58 -0700
Message-ID: <CAAWBYDAm4Dhb+DNxumdih230uZiQQx-9YueTCX3K7vR1wNVMWw@mail.gmail.com>
To: Mounir Lamouri <mounir@lamouri.fr>
Cc: "www-dom@w3.org" <www-dom@w3.org>
On Fri, Apr 19, 2013 at 3:31 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:
> On 18/04/13 19:13, Tab Atkins Jr. wrote:
>> On Thu, Apr 18, 2013 at 8:36 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:
>>> On 12/04/13 01:05, Tab Atkins Jr. wrote:
>>>> I propose that we change it so that, if at least one progress update
>>>> has already been made and the future isn't yet resolved, the progress
>>>> callback is immediately (next tick) called with the most recent
>>>> progress value.  That way the progress updates also act kinda like
>>>> futures in general, which is nice.
>>> I guess it would be good to have the callback being called synchronously
>>> in that case maybe (assuming ProgressFuture specification re-uses the
>>> synchronous flag).
>> I don't think it should run synch.  It's important, to keep reasoning
>> about Futures sane, that everything run consistently async.
> Sorry if it wasn't clear but I meant that running the callback should be
> sync, not getting the value. That way, we save one round trip to the
> event loop.
>>> Also, I think we should call .progress() such as .then() when the
>>> ProgressFuture is done.
>> Hmm, maybe.  I'm not sure.
> The reason why I asked that is for the use case where you have a UI like
> a progress bar being filed: having a last call to progress() my reduce a
> bit the burden of the developers so they don't have to special case
> .then() to draw the progress bar.
> Also, but I am not sure this is actually a real use case: maybe some
> callers will not care much about the .then() but just want to get
> information about the progress. For example, we can imagine that a UI
> component will get a ProgressFuture instance and a backend will get the
> same object. The backend will not care much about the progress but the
> UI might just care about that and not much about the fact that the
> action is done.

Yes, these arguments are reasonable.  I think I support having
ProgressFutures automatically send a final progress when they accept.
(Technically, sent before the acceptance, so the last progress handler
will be called before the accept handler.)

Received on Friday, 19 April 2013 16:50:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC