Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 


On 2/18/2010 5:31 AM, Jeremy Orlow wrote:
> On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp <kris@sitepen.com
> <mailto:kris@sitepen.com>> wrote:
>
>     * Use promises for async interfaces - In server side JavaScript,
>     most
>     projects are moving towards using promises for asynchronous
>     interfaces
>     instead of trying to define the specific callback parameters for
>     each
>     interface. I believe the advantages of using promises over callbacks
>     are pretty well understood in terms of decoupling async
>     semantics from
>     interface definitions, and improving encapsulation of concerns. For
>     the indexed database API this would mean that sync and async
>     interfaces could essentially look the same except sync would return
>     completed values and async would return promises. I realize that
>     defining a promise interface would have implications beyond the
>     indexed database API, as the goal of promises is to provide a
>     consistent interface for asynchronous interaction across components,
>     but perhaps this would be a good time for the W3C to define such an
>     API. It seems like the indexed database API would be a perfect
>     interface to leverage promises. If you are interested in proposal,
>     there is one from CommonJS here [1] (the get() and call() wouldn't
>     apply here). With this interface, a promise.then(callback,
>     errorHandler) function is the only function a promise would need to
>     provide.
>
>
>     [1] http://wiki.commonjs.org/wiki/Promises
>
>
> Very interesting.  The general concept seems promising and fairly
> flexible.  You can easily code in a similar style to normal
> async/callback semantics, but it seems like you have a lot more
> flexibility.  I do have a few questions though.
>
> Are there any good examples of these used in the wild that you can
> point me towards?  I used my imagination for prototyping up some
> examples, but it'd be great to see some real examples + be able to
> see the exact semantics used in those implementations.

Promises are heavily used in the E programming language, the Twisted
project (python). In JavaScript land, Dojo's Deferred's are an example
of a form of promises and a number of SSJS projects including Node and
Narwhal. To see some examples, you can look at the Dojo's docs [1]
(note that Dojo's spells it "addCallback" and "addErrback" instead of
"then", however we are looking to possibly move to the CommonJS
promise for Dojo 2.0). Here is somewhat random example of module that
uses Deferred's [2]
[1] http://api.dojotoolkit.org/jsdoc/1.3/dojo.Deferred
[2]
http://download.dojotoolkit.org/release-1.4.1/dojo-release-1.4.1/dojox/rpc/JsonRest.js


>
> I see that you can supply an error handling callback to .then(), but
> does that only apply to the one operation?  I could easily imagine
> emulating try/catch type semantics and have errors continue down the
> line of .then's until someone handles it.  It might even make sense
> to allow the error handlers to re-raise (i.e. allow to
> bubble) errors so that later routines would get them as well.
Yes, that's exactly right, errors can be raised/thrown and propagate
(when an error handling callback is not provided) to the next promise,
and be caught (with an error handler) just as you have expected from
the analogous propagation of errors across stack frames in JS.

> Maybe you'd even want it to bubble by default?  What have other
> implementations done with this stuff?  What is the most robust and
> least cumbersome for typical applications?  (And, in te complete
> absence of real experience, are there any expert opinions on what
> might work?)
>
I think it is pretty clear you want propagation, just like with normal
sync errors, it is very handy to have a catch/error handler low down
in the stack to generically handle various errors.
> Overall this seems fairly promising and not that hard to implement.
>  Do others see pitfalls that I'm missing?

There are certainly numerous design decisions that can be made with
promises.
* If an error occurs and an error handler is not provided in the
current event turn (note that an event handler can be provided at any
point in the future), should the error be logged somewhere?
* If an callback handler is added to an already fulfilled promise,
should the callback be executed immediately or in the next event turn?
Most JS impls execute immediately, but E suggests otherwise.
* One pitfall that a number of prior implementations have made is in
having callback's return value mutate the current promise instead of
returning the new one, the CommonJS spec makes it clear that then()
should return a new promise that receives the return values from the
callback.

- -- 
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkt9aNIACgkQ9VpNnHc4zAxMBgCfUG0/CVTgV15MBe8uQRDc6RPW
CwkAnjRiwt75g6yUpZ2dnnY5gv0LYpmh
=R2Qj
-----END PGP SIGNATURE-----