W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

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

From: Nikunj Mehta <nikunj@o-micron.com>
Date: Thu, 4 Mar 2010 11:44:56 -0800
Cc: Aaron Boodman <aa@google.com>, Jeremy Orlow <jorlow@google.com>, public-webapps WG <public-webapps@w3.org>
Message-Id: <E1131805-0F32-4675-BF50-851BA00DE447@o-micron.com>
To: Kris Zyp <kris@sitepen.com>

On Mar 4, 2010, at 10:55 AM, Kris Zyp wrote:

> On 3/4/2010 11:46 AM, Nikunj Mehta wrote:
> >
>  > On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote:
>  >
>  >>
>  >> On 3/4/2010 11:08 AM, Aaron Boodman wrote:
>  > [snip]
>  >>>
>  >>> * 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.
>
> The IndexedDB spec isn't and can't just sit back and not define the
> asynchronous interface. Like it or not, IndexedDB has defined a
> promise-like entity with the |DBRequest| interface. Why is inventing a
> new (and somewhat ugly) flower better than designing based on the many
> flowers that have already bloomed?

I meant to say that the IndexedDB spec should be updated to use a  
model that supports promises. If the current one is not adequate then,  
by all means, let's make it. However, we don't need a full-fledged  
promises in IndexedDB. I hope you agree this time.
Received on Thursday, 4 March 2010 19:46:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:37 GMT