The reason to do Promises and Streams is to make it easier for Platform
APIs to interop with each other.
An example I like to use is:
import Canvas from "web/html/canvas";
import fetch from "web/network/fetch";
class MyImage extends Canvas {
ready() {
fetch(this.src).pipe(this);
}
}
In this example, the fetch method returns a standard stream which can be
piped into the canvas tag.
You could imagine a video tag having an audio and video input stream, which
WebRTC pipes into. You could imagine grabbing the stream from an audio tag
and piping it into the video tag's input stream.
This isn't as urgent as long-overdue capabilities (because you can wrap
many kinds of APIs in something consistent), but having a few abstractions
for dealing with async values (promises and streams) makes libraries much
more composable with each other.
Yehuda Katz
(ph) 718.877.1325
On Tue, Jun 11, 2013 at 3:52 PM, Tobie Langel <tobie@w3.org> wrote:
> On Jun 12, 2013, at 6:22, Andrea Giammarchi <andrea.giammarchi@gmail.com>
> wrote:
>
> > with that I mean ... I don't care about Promises as much as I'd like to
> see Push Notification concretely implemented cross browser for real Web
> Apps plus all lower level hardware access FirefoxOS has that W3C is not
> even mentioning.
>
> That what is happening in the sys apps group, fwiw.
>
> --tobie
>