- From: Stefan H�kansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Tue, 4 Jun 2013 13:59:59 +0000
- To: Jan-Ivar Bruaroey <jib@mozilla.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 6/3/13 11:39 PM, Jan-Ivar Bruaroey wrote: > On 5/28/13 5:35 AM, Anne van Kesteren wrote: >> I was asked to email a brief overview here in preparation of the call next week. >> >> == Introduction == >> >> A future basically represents a value that may not yet have been >> computed. Since we lacked that concept thus far we've been emulating >> it with events (ondone/onerror) and callbacks (successCallback, >> failureCallback) in a somewhat mixed and adhoc fashion. >> >> Also, by making this a new type we can do interesting things with that >> type such as grouping. See http://dom.spec.whatwg.org/#futures for >> more information. > Hi everyone. > > Let me admit that I read about DOM Futures for the first time today at > https://github.com/slightlyoff/DOMFuture so it's still a bit of a > head-rush, but a welcome one, as I'd been scratching my head about how > our api could be made easier. > > I like it! - TL;DR: Success/failure callbacks encapsulated in > primary-return object let you write robust asynchronous code linearly. I like it too! But the fact that we have functionality out there, being used and experimented with a lot, makes things a bit more difficult I think. No one has given an indication when Futures will be supported, and I don't think we could change the APIs to use Futures and then tell users of our APIs to wait around until it is supported. I would expect us to eventually move to support Futures, but how and when is unclear to me (I guess we will discuss this further tomorrow).
Received on Tuesday, 4 June 2013 14:00:31 UTC