- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 19 Apr 2013 09:49:58 -0700
- 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.) ~TJ
Received on Friday, 19 April 2013 16:50:45 UTC