[futures] Persistent/Repeated Future that doesn't resolve

While redesigning the CSS Font Load Events api to use Futures, I ran
into a case where I needed to stick with events, even though they're
suboptimal and something more future-like would be better.

The current api proposal at
<http://wiki.csswg.org/ideas/font-load-futures>.  Look at the
loading/loadingdone events - these are used to allow an author to
provide loading UI indicating to the user whether fonts are loading at
any given time.  Because font loading can start and finish multiple
time across a document's life, this can't be done as a future
currently - there's no concept of "resolving" to hook off of.
However, events aren't well-suited for this either, as you can't tell
what the "current" state of loading is at the time you register
events.  Plus, while this exact case won't ever have errors, other
similar cases may, so they'd need to add an error event too.

Basically, what I need is something like a ProgressFuture (after the
"immediately ping with most recent value" change from my previous
email), but which never completes.  That way I could just register a
callback, get called in the next tick with the current value, and then
called again every time the value is updated, forever.

My immediate thoughts are that maybe this can be a ProgressFuture
which is specified to never resolve.

Another thought is to create a normal future (or a new type of future)
that resolves multiple times.  This would let you use .then() as
normal, rather than having to hook both .progress() and
.then(null,...) if you want to listen for errors as well.  This might
play better in the futures algebra, too, though it would need special
handling - for the purpose of all other future combinators, it would
act like it was initially unresolved and resolves the next time it
receives a "progress update".

If I pretend it's something like the latter, I'd be able to tweak Font
Load Events to have a .ready() method returning a normal Future, for
running code whenever font loads aren't currently running, and a
.status() method return a MultiFuture that alternates between sending
"loading" and "loaded" progress values.

Thoughts?

~TJ

Received on Thursday, 11 April 2013 23:24:34 UTC