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

On Thu, Mar 4, 2010 at 7:44 PM, Nikunj Mehta <nikunj@o-micron.com> wrote:

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

FWIW, I agree.


To get promises to work with the current event based implementation, it'd be
somewhat complex.  Since there can only be one request in flight at a time,
the implementation would need to know which requests would be using the same
request object and implement a queue for each one (or implement a global
queue if that's not practical).  Whenever an onsuccess or onerror callback
is called, it'd need to check to see if there are any queued up requests
(and would fire them if so).  This seems complex and ugly, but certainly
possible.

If the interface were callback based, a library would simply create a
promise object, create an onsuccess closure, create an onerror closure, and
pass those into the callbacks.  When the callbacks are called, they'd have a
reference to the promise (since they were created with access to the promise
object due to their scope) and could easily fulfill the promise.

Of course, I'm probably re-inventing the wheel here; there are enough other
callback based APIs that I assume this is a solved (and optimized problem).
 Are there any other APIs that use the request event based style like how
IndexedDB is currently specced?  If so, can anyone share any experience with
the list?  If not, does anyone foresee major problems and/or have an opinion
on how easy it'll be to adapt promises to the API?


For what it's worth, regardless of the answers to the above questions, I
think we should switch to a callback based model.  It's great to use events
when natural to do so, but this is a very unnatural use.  It provides
artificial limitations (only one request in flight at a time, per request
object).  It's ugly and confusing syntax wise (hard to keep track of which
request object is associated with which request method, requires multiple
statements to do each request, requires the handlers to be placed prior to
the actual call...which is why the async example in
http://www.w3.org/TR/IndexedDB/#introduction is so difficult to read, etc).
 And there really isn't any precedent (that I'm aware of) for using events
like this.  And the web developers I've spoken to have all been confused by
the async API.


I believe the API itself won't need to change much at all in order to make
callbacks work.  I'm happy to take a shot at making the necessary edits if
no one objects to changing the async API to a callback based one.

J