<div dir="ltr">I'd like to second the arguments made so far about helping others not intimate with the semantics of this discussion use promises in a less error-prone way. In general POLA violations can and will annoy developers, especially those who encounter Firefox code for the first time, coming from another community that uses a particular flavor of promises.<br>

<br>The initial goal of the add-on SDK promise implementation was to use the Q API, from which I assert it should follow that the Q async style should be used as well:<br><br><a href="http://documentup.com/kriskowal/q/#tutorial">http://documentup.com/kriskowal/q/#tutorial</a><br>

<br>Mark Miller argued convincingly IMHO about async being the better style, in the Q mailing list and in a position paper co-authored with Tom Van Cutsem:<br><br><a href="https://groups.google.com/forum/#!msg/q-continuum/dfH0Mlognys/1xJE3hkZiocJ">https://groups.google.com/forum/#!msg/q-continuum/dfH0Mlognys/1xJE3hkZiocJ</a><br>

<a href="http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/37626.pdf">http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/37626.pdf</a><br>

<br>Section 3 and Table 1 in that paper are worth reading.<br><br>Furthermore, the Promises/A+ spec that we seem to be considering as the most important one to follow, explicitly specifies async in section 3.2.4:<br><br>
<a href="http://promises-aplus.github.com/promises-spec/">http://promises-aplus.github.com/promises-spec/</a><br>
<br>The arguments that went back and forth before reaching consensus on that are worth reading, too:<br><br><a href="https://github.com/promises-aplus/promises-spec/issues/4">https://github.com/promises-aplus/promises-spec/issues/4</a><br>

<br>One could argue that we should be skating to where the puck is going to be, and DOM Futures seem like the future (pun intended, but also unavoidable). It isn't entirely obvious to me from the current spec if they support async only or both, because I'm having a hard time parsing the specese around the "synchronous flag":<br>

<br><a href="http://dom.spec.whatwg.org/#futures">http://dom.spec.whatwg.org/#futures</a><br><br>But from other stuff I've read it seems that the expected behavior is async:<br><br><a href="https://github.com/slightlyoff/DOMFuture/issues/47">https://github.com/slightlyoff/DOMFuture/issues/47</a><br>

<a href="https://github.com/slightlyoff/DOMFuture/blob/master/DOMFuture.idl#L72-79">https://github.com/slightlyoff/DOMFuture/blob/master/DOMFuture.idl#L72-79</a><br><br>So, in summary, I think it's clear that we need both sync and async versions of the API, but being async by default seems to me like it strikes the right balance between allowing expert hackers writing performance-critical code to use promises, while at the same time being familiar to developers coming from Q, CommonJS, or the DOM spec, or just using promises after Googling for instructions.<br>

<br><br>Cheers,<br>Panos<br><br>P.S.: not that I ever google an API before using it, god forbid! Who does that anyway?</div>