[+kriskowal]
Hi Alex, there is a strawman <
http://wiki.ecmascript.org/doku.php?id=strawman:concurrency> that has
co-evolved through these discussions to be largely compatible with Promises
A+, Q, and DOMFuture where they overlap. As several have advised, this page
should be broken up into modular pieces. Also, we should recognize the
great work Domenic and Kris have done co-evolving Promises/A+ <
https://github.com/promises-aplus> and Q <https://github.com/kriskowal/q>.
Through these discussions and others, they have effectively served as an
informal but working standards process.
Part of your DOMFuture idl says "Compatibility with existing
promises/futures/deferreds libraries or terminology is a non-goal." When I
first read this, my inclination was to write off DOMFuture as irrelevant.
Clearly if such compatibility is a non-goal, then those other efforts
(including my own) should treat compatibility with DOMFuture as a non-goal.
Fortunately, you managed the DOMFuture discussions in practice in a
reasonable and productive manner, such that all sides could treat
convergence as a mutual goal, which I believe we've already largely
achieved. I think we're close.
On Thu, Mar 7, 2013 at 8:50 AM, Alex Russell <slightlyoff@google.com> wrote:
> Hi all,
>
> With the find folks on the CC list, I've been working for the past several
> months on a design for Futures (need "Promises") that are mutually
> acceptable to the interested TC39 members as well as key DOM API designers.
>
> This work is the fallout from the thread started here last year:
>
>
> https://mail.mozilla.org/pipermail/es-discuss/2012-November/thread.html#26188
>
> A public IDL design and p(r)ollyfill are now available:
>
> https://github.com/slightlyoff/DOMFuture/
>
> Many issues regarding the design are currently under discussion:
>
> https://github.com/slightlyoff/DOMFuture/issues?page=1&state=open
>
> The largest concerns about the core API semantics appear to be settled:
>
> https://github.com/slightlyoff/DOMFuture/issues?page=1&state=closed
>
> Next steps:
>
> Barring major objections, I would like to propose that we move this design
> forward in both DOM and in ES. If there is support, I will make an ES
> straw-man to capture the invariants of the design while continuing to work
> with DOM authors and designers to move this design into the web platform in
> preparation for the longer-term project of importing it (or a subset of it)
> into ES proper.
>
> Thoughts?
>
> Thanks
>
--
Cheers,
--MarkM