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

On Wed, Mar 3, 2010 at 4:49 AM, Kris Zyp <kris@sitepen.com> wrote:

>  -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 3/1/2010 2:52 PM, Jeremy Orlow wrote:
> > 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.
>
> Asynchronous counterparts to void-returning synchronous functions can
> still return promises. The promise would just resolve to undefined,
> but it still fulfills the role of indicating when the operation is
> complete.
>

Good point!  Silly me.


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

Any thoughts on whether we'd raise or ignore improper inputs?  I'm leaning
towards raise since it would be deterministic and silently ignoring seems
like a headache from a developer standpoint.


> > If there's an error, all onerror callbacks would be called with the
> > IDBDatabaseError.
>
> Yes.
>
>
> > Exceptions within callbacks would be ignored.
>
> With CommonJS promises, the promise returned by the then() call goes
> into an error state if a callback throws an exception. For example,
>
> someAsyncOperation.then(successHandler, function(){ throw new
> Error("test") })
>     .then(null, function(error){ console.log(error); });
>
> Would log the thrown error, effectively giving you a way of catching
> the error.
>
> Are you suggesting this as a simplification so that IndexedDB impls
> doesn't have to worry about recursive creation of promises? If so, I
> suppose that seems like a reasonable simplification to me. Although if
> promises are something that could be potentially reused in other
> specs, it would be nice to have a quality solution, and I don't think
> this is a big implementation burden, I've implemented the recursive
> capabilities in dozen or two lines of JS code. But if burden is too
> onerous, I am fine with the simplification.
>

When you say "recursive capabilities" are you just talking about how to
handle exceptions, or something more?

In terms of exceptions: I don't think it's an
enormous implementational burden and thus I think it's fine to ignore that
part of the equation.  So the question mainly comes down to whether the
added complexity is worth it.  Can you think of any real-world examples of
when this capability is useful in promises?  If so, that'd definitely help
us understand the pro's and con's.

> 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.
>
> Certainly the intent of promises is that there is exists only one
> generic promise interface that can be reused everywhere, at least from
> the JS perspective, not sure if the extra type constraints in IDL
> demand multiple interfaces to model promise's effectively
> parameterized generic type form.
>

Unfortunately, I don't really know.  Before we try speccing it, I'll
definitely see if any WebIDL experts have suggestions.


Also, do we want to explicitly spec what happens in the following case?

window.indexedDB.open(...).then(
    function(db) {  db.openObjectStore("a").then( function(os) {
alert("Opened a"); } ) }
).then(
    function(db) { alert("Second db opened"); }
);

Clearly the first function(db) is called first.  But the question is whether
it'd be a race of which alert is called first or whether the "Second db
opened" alert should always be shown first (since clearly if the first is
called, the second _can_ be fired immediately afterwards).

I'm on the fence about whether it'd be useful to spec that the entire chain
needs to be called one after the other before calling any other callbacks.
 Does anyone have thoughts on whether this is useful or not?  If we do spec
it to call the entire chain, then what happens if inside one of the
callbacks, something is added to the chain (via another .then() call).

J