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

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

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

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

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

- -- 
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/
 
iEYEARECAAYFAkuN6kkACgkQ9VpNnHc4zAwsewCfcqu8L1ZTSU0NUoAL5pG/i+uO
A98An1y2XK2ylsVxVwOxjrsWbn4Jd+y0
=7yq3
-----END PGP SIGNATURE-----