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

In RxJS, a "value over time" that will also give you the "current value" (defined as the value most recently observed) when you subscribe is provided with a BehaviorSubject (Here's the C# documentation for it, the RxJS version behaves similarly: http://msdn.microsoft.com/en-us/library/hh211949(v=vs.103).aspx).

And of course, in KnockoutJS, this is one of the core concepts and is implemented by their observables (http://knockoutjs.com/documentation/observables.html).



________________________________
 From: Jake Verbaten <raynos2@gmail.com>
To: Tab Atkins Jr. <jackalmage@gmail.com> 
Cc: Domenic Denicola <domenic@domenicdenicola.com>; "www-dom@w3.org" <www-dom@w3.org> 
Sent: Thursday, April 11, 2013 8:56 PM
Subject: 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
>
>