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 11:08 AM, Aaron Boodman wrote:
> On Thu, Feb 18, 2010 at 4:31 AM, Jeremy Orlow <jorlow@google.com>
> wrote:
>> On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp <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. 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.  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?) Overall this seems fairly promising
>> and not that hard to implement.  Do others see pitfalls that I'm
>> missing? J
>
> I disagree that IndexedDB should use promises, for several
> reasons:
>
> * Promises are only really useful when they are used ubiquitously
> throughout the platform, so that you can pass them around like
> references. In libraries like Dojo, MochiKit, and Twisted, this is
> exactly the situation. But in the web platform, this would be the
> first such API. Without places to pass a promise to, all you
> really have is a lot of additional complexity.

I certainly agree that promises are more useful when used
ubiquitously. However, promises have many advantages besides just
being a common interface for asynchronous operations, including
interface simplicity, composibility, and separation of concerns. But,
your point about this being the first such API is really important. If
we are going to use promises in the IndexedDB, I think they should the
webapps group should be looking at them beyond the scope of just the
IndexedDB API, and how they could be used in other APIs, such that
common interface advantage could be realized. Looking at the broad
perspective is key here.
>
> * ISTM that the entire space is still evolving quite rapidly. Many
> JavaScript libraries have implemented a form of this, and this
> proposal is also slightly different from any of them. I think it
> is premature to have browsers implement this while library authors
> are still hashing out best practice. Once it is in browsers, it's
> forever.
Promises have been around for a number of years, we already have a lot
of experience to draw from, this isn't exactly a brand new idea,
promises are a well-established concept. The CommonJS proposal is
nothing ground breaking, it is more based on the culmination of ideas
of Dojo, ref_send and others. It is also worth noting that a number of
JS libraries have expressed interest in moving towards the CommonJS
promise proposal, and Dojo will probably support them in 1.5.
>
> * There is nothing preventing JS authors from implementing a
> promise-style API on top of IndexedDB, if that is what they want
> to do.
>
Yes, you can always make an API harder to use so that JS authors have
more they can do with it ;). But it is true, we can build promises on
top of an plain event-based IndexedDB API.

- -- 
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/
 
iEYEARECAAYFAkuP+qgACgkQ9VpNnHc4zAybzACfTdCsTuh8ZWqQHsK5eEnYFcn4
WwUAn2MsNBQ9luCPXg63Z+/l9iSv5axt
=7oEu
-----END PGP SIGNATURE-----

Received on Thursday, 4 March 2010 18:26:00 UTC