- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Fri, 19 Apr 2013 12:31:04 +0200
- 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. -- Mounir
Received on Friday, 19 April 2013 10:31:27 UTC