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

Re: [futures] Making ProgressFuture immediate

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Fri, 19 Apr 2013 12:31:04 +0200
Message-ID: <51711CE8.1030402@lamouri.fr>
To: www-dom@w3.org
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.

Received on Friday, 19 April 2013 10:31:27 UTC

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