On Thu, Mar 4, 2010 at 6:46 PM, Nikunj Mehta <nikunj@o-micron.com> wrote:
>
> On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote:
>
>
>> 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.
>>
>
> In general, IndexedDB has taken an approach of leaving ease of programming
> to libraries. There seems to be a good case to build libraries to make
> asynchronous programming with IndexedDB easier through the use of such
> mechanisms as promises. In fact, IndexedDB might be yet another area for
> libraries to slug it out.
>
>
>
>>> * 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.
>>
>
> I feel that we should avoid taking a general position on promises in this
> spec. At the same time, we should ascertain that promises can be overlaid on
> IndexedDB since that appears to be a promising style of async programming.
>
>
>
>>> * 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 ;).
>>
>
> You will agree that we don't want to wait for one style of promises to win
> out over others before IndexedDB can be made available to programmers. Till
> the soil and let a thousand flowers bloom.
>
>
> But it is true, we can build promises on
>> top of an plain event-based IndexedDB API.
>>
>
> I think that more or less seals the case, IMO.
>
Kris, you meant callback based API, correct?
I believe that an API wrapping a callback based IndexedDB can operate
very elegantly, but one operating on the event based model would be
significantly more complex since only one request can be inflight at a time
per request object.
In light of the comments since my last email, I think I'm pretty convinced
that we should not go the promise based route at this time. That said, I do
feel VERY strongly that a callback based model is superior to the current
event based model though. And the various web developers I've talked to
within Google have all agreed as well. Are there any who disagree with
changing the asynchronous model to a callback based one?
J