Re: DOM Futures

Hi Greg,

     It is my understanding that Futures are only appropriate for 
callbacks that get fired once (not for repetitive events). For an 
example of what an API sniplet would look like after Futures see the 
bottom of: 
http://lists.w3.org/Archives/Public/public-webrtc/2013Jun/0058.html

Gili

On 15/07/2013 12:26 PM, Greg Billock wrote:
> Thanks for the link to the minutes.
>
> I don't necessarily want to revisit the entire discussion, but it 
> might be valuable to become concrete with a sense of what changes a 
> Promise-based recording API would entail. Currently the model is that 
> the recorder is an EventTarget. You hook it up to a stream and push 
> the record() button, and then ondataavailable events start coming out 
> with encoded bytes. Other buttons on the recorder then hook up 
> asynchronously to it's various event productions.
>
> Alex, have you looked at this to formulate an alternative?
>
>
>
>
> On Mon, Jul 15, 2013 at 8:34 AM, Bjoern Hoehrmann <derhoermi@gmx.net 
> <mailto:derhoermi@gmx.net>> wrote:
>
>     * Alex Russell wrote:
>     >On Sun, Jul 14, 2013 at 10:34 PM, Bjoern Hoehrmann
>     <derhoermi@gmx.net <mailto:derhoermi@gmx.net>>wrote:
>     >
>     >> * cowwoc wrote:
>     >> > 3. Revisiting DOM Futures in light of the fact that the API
>     has been
>     >> >    officially frozen since our last meeting:
>     >> > http://lists.w3.org/Archives/Public/www-tag/2013Jun/0075.html
>     >>
>     >> Tab Atkins told people "The spec is done." already back in
>     mid-april,
>     >>
>     http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0146
>     >> and much has changed since.
>     >
>     >This is inaccurate. Very little has changed. Semantically, only one
>     >corner-case is handled differently, and even then only in an
>     observable way
>     >under special conditions. The naming has changed for some
>     methods, but this
>     >was anticipated and indicates EVEN GREATER stability as it has been
>     >accepted by both TC39 and in the draft DOM spec.
>
>     My purpose was to make sure people understand what words like
>     "done" and
>     "frozen" mean. Let's see, the API changed among minor things thus:
>
>       FutureResolver -> PromiseResolver
>         .accept -> .fulfill
>
>       Future -> Promise
>         .done -> ???
>
>       + Promise.fulfill
>       + Promise.resolve
>       + Promise.reject
>
>     Plus behavioral changes. When I tell somebody a specification I
>     work on
>     is "done" or tell them an API is "frozen" then they can be sure
>     that it
>     is no longer possible to make changes of this magnitude. To you
>     and Tab
>     Atkins the words obviously mean something else; it's good to have that
>     on record.
>
>     You might also want to clarify what Tab Atkins meant when he said that
>     "Promises aren't going to be a W3C deliverable anyway" in the message
>     above, considering your efforts to get "Promises" into W3C
>     deliverables.
>     --
>     Björn Höhrmann · mailto:bjoern@hoehrmann.de
>     <mailto:bjoern@hoehrmann.de> · http://bjoern.hoehrmann.de
>     Am Badedeich 7 · Telefon: +49(0)160/4415681
>     <tel:%2B49%280%29160%2F4415681> · http://www.bjoernsworld.de
>     25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·
>     http://www.websitedev.de/
>
>