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

On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp <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.

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.  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?)

Overall this seems fairly promising and not that hard to implement.  Do
others see pitfalls that I'm missing?

J