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

On Thu, Mar 4, 2010 at 5:46 PM, Kris Zyp <kris@sitepen.com> wrote:

>  -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 3/4/2010 10:35 AM, Mark S. Miller wrote:
> > On Thu, Mar 4, 2010 at 6:37 AM, Jeremy Orlow <jorlow@chromium.org
> > <mailto:jorlow@chromium.org> <jorlow@chromium.org>> wrote:
> >
> > You are quite right!  I misunderstood how this part of promises
> > worked.
> >
> > Is there excitement about speccing promises in general?
> >
> >
> > Yes. The starting point for a lot of the commonjs promises work is
> > Tyler's ref_send promise library, documented at
> > <http://waterken.sourceforge.net/web_send/#Q><http://waterken.sourceforge.net/web_send/#Q>.
> The commonjs work
> > got more complicated than this in order to try to accommodate
> > legacy deferred-based usage patterns within the same framework.
> > While it may have helped adoption within the commonjs community,
> > IMO this extra complexity should not be in any standard promise
> > spec. Caja implements Tyler's spec without the extra complexity,
> > and we're quite happy with it.
> >
> > I hope to work with Tyler and others to propose this to the
> > EcmaScript committee as part of a more general proposal for a
> > communicating-event-loops concurrency and distribution framework
> > for future EcmaScript. Don't hold your breath though, this is not
> > yet even an EcmaScript strawman. Neither is there any general
> > consensus on the EcmaScript committee that EcmaScript should be
> > extended in these directions. In the meantime, I suggest just using
> > Tyler's ref_send and web_send libraries.
>
>
> It would be great if promises become first class, but obviously the
> IndexedDB specification can't be dependent on someone's JS library.
>
> >
> >
> >
> > If not, it seems a little odd to spec such a powerful mechanism
> > into just IndexedDB....and it might be best to spec the simplified
> > version of .then(): .then() will return undefined,
> > onsuccess/onerror's return values will be swallowed, and any thrown
> > exceptions will be thrown.
> >
> > This should make it easy to make IndexedDB support full blown
> > promises if/whenever they're specced.  (It's not clear to me
> > whether UA support for them would offer enough advantages to
> > warrant it.)
> >
> >
> > Note that ref_send exposes the .then() style functionality as a
> > static .when() method on Q rather than an instance .then() method
> > on promises. This is important, as it 1) allows resolved values to
> > be used where a promise is expected, and 2) it protects the caller
> > from interleavings happening during their Q.when() call, even if
> > the alleged promise they are operating on is something else.
>

Thanks a lot for your feedback!  This is very valuable and definitely
provided some food for thought.  I started working on a rambly email about
the pro's and cons of "when" when I saw Kris's response.


> The .then() function is in no way intended to be a replacement for a
> static .when() function. In contrast to ref_send, having promises
> defined by having a .then() function is in lieu of ref_send's
> definition of a promise where the promise is a function that must be
> called:
> promise("WHEN", callback, errback);
> This group can consider it an API like this, but I don't think that
> IndexedDB or any other W3C API would want to define promises in that
> way, as it is pretty awkward. Using .then() based promises in no way
> precludes the use of Q.when() implementations which meet both your
> criteria for safe operation. However, these can easily be implemented
> in JS, and I don't think the IndexedDB API needs to worry about such
> promise libraries.
>

Which is basically what I had arrived at in my mind as well.

It'll definitely be interesting to see how the EMCAScript side of promises
shapes up.  But in the mean time, I think the simpler version that we've
been discussing will be a good balance of features but minimized API surface
area...and keeping chances high that what ends up being standardized would
fit in well with the API.

At this point, I feel fairly confident that using a scaled down version of
promises would work well in IndexedDB.  But, at the same time, a callback
based API would be much more standard and it wouldn't be that hard for
someone to build a promise based library around IndexedDB.  Nikunj, Pablo,
Mozilla, etc...what do you think is the best way forward here?  Should we
give scaled back promises a shot?  Or should we just go with a callback
based approach?

J


Summary of what I'm currently thinking we should do, if we go with a
"Promises" type async API:

Each async function would return a promise.  A promise has one method:
".then()".  Then takes up to two callbacks. The first is onsuccess.  The
second is onerror.  You can call .then() before and after the async call has
finished--in fact, there's no way to know for sure whether it has finished
before you call .then() (but that's fine).  If you pass in garbage to the
callbacks, it'll throw an exception, but null/undefined and omitting them is
fine.  When the promise is ready to fire the callbacks, it'll always do it

And that's pretty much it.