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

Re: [futures] Making ProgressFuture immediate

From: Jake Verbaten <raynos2@gmail.com>
Date: Thu, 11 Apr 2013 18:37:50 -0700
Message-ID: <CAMCMjp0axgssCaTxJ0va7AdPgWxs39tBYNS2V7Wsxn8U-wArnA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "www-dom@w3.org" <www-dom@w3.org>
> That prevents you from initializing the progress UI with the "current"

The abstraction your looking for is a representation of a value over time.
I don't think a Future is a good abstraction to model this.

There is a ton of prior art on representing values over time in FRP in
terms of signals (
http://en.wikipedia.org/wiki/Functional_reactive_programming )

Rather then overloading a `Future` which is a representation of either a
concrete value or a failure which will be known at some point in the future
we may want to consider representing the progress use-case as a changing

For JavaScript implementations, RxJS calls this an "Observable" (
https://github.com/Reactive-Extensions/RxJS/wiki/Observable ) and bacon.js
calls this a Property ( https://github.com/raimohanska/bacon.js#property ).
Dominictarr also has a minimal 200 line implementation of this idea (
https://github.com/dominictarr/observable )

The reason I mention FRP & signals is that it's the only abstraction I know
of that's kind of similar to events & futures but actively capture and
models the notion of "current state" in a period of time.

I've personally found having an abstraction that's like an event but also
captures current state is a powerful tool for asynchronous programming.

On Thu, Apr 11, 2013 at 4:05 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> A common use-case for ProgressFuture will be using the progress values
> to drive progress UI for the user.  However, the current design is
> flawed for this use-case.  Right now, the progress callback is only
> called when the future's resolver posts a new progress update.  That
> prevents you from initializing the progress UI with the "current"
> progress - you have to wait until the next heartbeat occurs, which may
> be an arbitrary amount of time in the future.  This is precisely the
> sort of "just missed it" race condition that futures were designed to
> avoid.
> 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.
> ~TJ
Received on Friday, 12 April 2013 01:38:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:02 UTC