- From: Nikunj Mehta <nikunj@o-micron.com>
- Date: Thu, 4 Mar 2010 11:44:56 -0800
- To: Kris Zyp <kris@sitepen.com>
- Cc: Aaron Boodman <aa@google.com>, Jeremy Orlow <jorlow@google.com>, public-webapps WG <public-webapps@w3.org>
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 UTC