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

> Hm, Streams *might* work.  However, it looks like they usually still
fall prey to the "can only see the *next* update after subscribing"
problem.  If we had something that would inform you of the
most-recently-published value as well when you subscribed, it would
probably work better.  If I'm reading correctly, they also
automatically feed you the entire history of the stream, while the
use-cases I'm thinking of just need to know the "current" state and
future states.

Streams should not feed you the entire history, they should just give you
new events.

I also feel that progress is out of scope for Future as they represent a
single value to be known in the future with correct error propagation
mechanisms.

As mentioned in another thread (
http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0022.html ) you
probably want to look into an FRP style signal (
http://en.wikipedia.org/wiki/Functional_reactive_programming ) which is a
representation of a value over time. It's the only async data structure I
know of that specifically models current state at a moment in time.

RXJS ( https://github.com/Reactive-Extensions/RxJS/wiki/Observable ) and
bacon ( https://github.com/raimohanska/bacon.js#property ) have
implementations of this idea. Elm (a compile to JavaScript language) also
has good implementations of this idea (
http://elm-lang.org/learn/What-is-FRP.elm )

It would probably look like

interface Signal {
  void listen(valueListener);
  Any value();
}

Where you can ask it for it's current value synchronously by calling
value() and you can listen to any future changes by calling
listen(function). It should be noted that the representation of a value
over time is not a representation for an asynchronous task that may cause
an error, that's a seperate thing.

Your font future may have an attribute called "completionStatus" that is a
signal. It should also be noted that signals require an initial value. In
the case of the loading status of a font it would default to 0 (assuming
it's modeled as a number from 0 to 100).

It should also be noted that streams do not have a notion of "current
value" for good reasons. The notion of "current value" means that a) you
need to maintain state on something that could be stateless. b) it needs to
have an initial state before it has started and c) you need to look at the
state of a stream in between two events and that state needs to make
coherent sense. Just saying that the state is the last event is not always
a meaningful thing.


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

> On Thu, Apr 11, 2013 at 5:05 PM, Domenic Denicola
> <domenic@domenicdenicola.com> wrote:
> > I think this isn't a great use case for promises. Indeed, I don't think
> progress in general is a good use case for promises: it doesn't fit the
> sync/async function call parallel that they try to model.
>
> Progress seems to be a necessary case for promises, unless you want to
> break consistency for what is otherwise a trivial addition - there are
> plenty of actions which definitely complete at some point, and which
> you want to respond to the completion of in the promises fashion (if
> completed, notify me immediately, otherwise notify me when it
> completes), but which also can usefully hand out progress information.
>  It seems like "partial" completion is very near to "completion"
> thematically, and so the two should be addressed in a similar/close
> fashion if possible.
>
> > Rather, what you're looking for is probably something more like an event
> stream, from functional reactive programming. The more interesting
> implementations of these that I have seen include [RxJS][] and [Dart's
> stream API][]. There is some hope of getting something like this in the
> DOM, and having use cases like this are very helpful toward that work, but
> I don't think any ideas have gelled yet into something usable. It's very
> tricky to get right.
>
> Hm, Streams *might* work.  However, it looks like they usually still
> fall prey to the "can only see the *next* update after subscribing"
> problem.  If we had something that would inform you of the
> most-recently-published value as well when you subscribed, it would
> probably work better.  If I'm reading correctly, they also
> automatically feed you the entire history of the stream, while the
> use-cases I'm thinking of just need to know the "current" state and
> future states.
>
> I'm thinking something like this:
>
> interface EventStream {
>   EventStream attribute listen(valueCB, errorCB);
>   Future next(valueCB, errorCB);
> }
>
> In listen(), valueCB is called every time a new value is pushed, and
> immediately (next tick) with the most recently pushed value if at
> least one value as already been pushed.  errorCB is called when the
> stream's resolver rejects, which also kills the stream.  It returns
> the same stream, for chaining.
>
> next() returns a Future for the next value to be pushed, constructed
> with valueCB and errorCB.
>
> ~TJ
>
>