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

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

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.

- -- 
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/
 
iEYEARECAAYFAkuP8f0ACgkQ9VpNnHc4zAwm9gCfajBUy0PZpaxvSctlorVeYIsK
yQwAnAwtSd6BWPbpOOJTniZcojmNFQtw
=GHjA
-----END PGP SIGNATURE-----