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

Thanks for the pointers.  I'm actually pretty sold on the general idea of
promises, and my intuition is that there won't be a very big resource
penalty for using an API like this rather than callbacks or what's currently
specced.  At the same time, it seems as though there isn't much of a
standard in terms of the precise semantics and some of the techniques (such
as optionally taking callbacks and not returning a promise if they are
supplied) seems like a decent answer for pure javascript APIs, but maybe not
as good for IDL and a standard like this.

Do you guys have any recommendations for the precise semantics we'd use, if
we used promises in IndexedDB?  To get started, let me list what I'd propose
and maybe you can offer counter proposals or feedback on what would or
wouldn't work?


Each method on a ____Request interface (the async ones in the spec) whose
counterpart returns something other than void would instead return a
Promise.

The promises would only have a "then" method which would take in an
onsuccess and onerror callback.  Both are optional.  The onsuccess function
should take in a single parameter which matches the return value of the
synchronous counterpart.  The onerror function should take in an
IDBDatabaseError.  If the callbacks are null, undefined, or omitted, they're
ignored.  If they're anything else, we should probably either raise an
exception immediately or ignore them.

If there's an error, all onerror callbacks would be called with the
IDBDatabaseError.

Exceptions within callbacks would be ignored.


In terms of speccing, I'm not sure if we can get away with speccing one
promise interface or whether we'd need to create one for each type of
promise.


On Thu, Feb 18, 2010 at 4:20 PM, Kris Zyp <kris@sitepen.com> wrote:

>  -----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> <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-----
>
>