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

On Fri, Mar 12, 2010 at 1:05 AM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:

> On 3/5/2010 4:54 AM, Jeremy Orlow wrote:
>
>> 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.
>>
> For what it is worth, all the web developers we've talked to have pushed
> for an event based API, which is why we've been pushing for it.  This
> happened with the file reader API as I understand it (Jonas or Arun would be
> able to say more).
>
> Note that we didn't show them this exact API.
>

I totally believe that, from a high level, an event based API is desirable.
 When done well, event based models are quite nice because they follow the
same patterns and are typically easier to read.  But I'm not sure if there's
a way to make an event based model work for IndexedDB.

I suppose you could do something promise-like where each function call would
return an object that you could register an event on.  But syntax wise, that
means every method call would require at least 3 lines (if you register both
an onsuccess and onerror handler).  It'd also be a pretty heavy weight
solution.

Another possibility is that you could optionally allow the user to pass in
an identifier to every method call and then pass this in to the event.  This
would make it possible for the same request object to be shared between
multiple in-flight requests, but still allow the user (or library) to sort
out which request got which response.


Is it possible to run the current API, some of these options, and a callback
API past some of the developers you talked to and see what they think?