W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [IndexDB] Proposal for async API changes

From: Shawn Wilsher <sdwilsh@mozilla.com>
Date: Wed, 09 Jun 2010 15:51:24 -0700
Message-ID: <4C101AEC.1010000@mozilla.com>
To: Kris Zyp <kris@sitepen.com>
CC: Jonas Sicking <jonas@sicking.cc>, Laxmi Narsimha Rao Oruganti <Laxmi.Oruganti@microsoft.com>, Jeremy Orlow <jorlow@chromium.org>, Webapps WG <public-webapps@w3.org>
On 6/9/2010 3:48 PM, Kris Zyp wrote:
> Another option would be to have cursors essentially implement a JS
> array-like API:
>
> db.objectStore("foo").openCursor(range).forEach(function(object){
>    // do something with each object
> }).onsuccess = function(){
>     // all done
> });
>
> (Or perhaps the cursor with a forEach would be nested inside a
> callback, not sure).
>
> The standard "some" function is also useful if you know you probably
> won't need to iterate through everything
>
> db.objectStore("foo").openCursor(range).some(function(object){
>    return object.name == "John";
> }).onsuccess = function(johnIsInDatabase){
>     if(johnIsInDatabase){
>       ...
>     }
> });
>
> This allows us to have an async interface (the callbacks can be called
> at any time) and still follows normal JS array patterns, for
> programmer convenience (so programmers wouldn't need to iterate over a
> cursor and push the results into another array). I don't think anyone
> would miss getAll() with this design, since cursors would already be
> array-like.
To me, this feels like we are basically doing what we expect a library 
to do: make the syntactic sugar work.  I don't see why a library 
couldn't provide a some or forEach method with the currently proposed API.

Cheers,

Shawn



Received on Wednesday, 9 June 2010 22:52:37 GMT

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