- From: Aaron Boodman <aa@google.com>
- Date: Thu, 4 Mar 2010 10:08:07 -0800
- To: Jeremy Orlow <jorlow@google.com>
- Cc: Kris Zyp <kris@sitepen.com>, public-webapps <public-webapps@w3.org>
On Thu, Feb 18, 2010 at 4:31 AM, Jeremy Orlow <jorlow@google.com> wrote: > 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 I disagree that IndexedDB should use promises, for several reasons: * Promises are only really useful when they are used ubiquitously throughout the platform, so that you can pass them around like references. In libraries like Dojo, MochiKit, and Twisted, this is exactly the situation. But in the web platform, this would be the first such API. Without places to pass a promise to, all you really have is a lot of additional complexity. * ISTM that the entire space is still evolving quite rapidly. Many JavaScript libraries have implemented a form of this, and this proposal is also slightly different from any of them. I think it is premature to have browsers implement this while library authors are still hashing out best practice. Once it is in browsers, it's forever. * There is nothing preventing JS authors from implementing a promise-style API on top of IndexedDB, if that is what they want to do. - a
Received on Thursday, 4 March 2010 18:08:36 UTC