- From: Kris Zyp <kris@sitepen.com>
- Date: Fri, 12 Mar 2010 10:52:25 -0700
- To: Aaron Boodman <aa@google.com>
- CC: Jeremy Orlow <jorlow@chromium.org>, Shawn Wilsher <sdwilsh@mozilla.com>, Nikunj Mehta <nikunj@o-micron.com>, public-webapps WG <public-webapps@w3.org>, Arun Ranganathan <aranganathan@mozilla.com>, Jonas Sicking <sicking@mozilla.com>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Would it possibly be more appropriate and expedient to only provide a sync API for now (and defer async support to possibly a later version)? It seems like the design of IndexedDB is such that most operations should occur in O(log n) time, and probably will be easily done under 100ms the majority of the time, and often under 10ms (especially with caching and such). With such short execution times, asynchronous APIs seem less crucial (than XHR for example, that can be very long-running) since IndexedDB blocking times are generally less than a user can perceive (and the concurrency benefits of async would largely be lost on single user browser apps). Anyway, I am not necessarily opposed to an async API, just wondering about the value, especially with the current design being pretty awkward to use as you pointed out. Kris On 3/12/2010 10:05 AM, Aaron Boodman wrote: > I haven't been following the discussion with IndexedDB closely, but I > think the general ID of an indexed name/value store is a great idea, > and would be Good for the web. > > However, I do agree with Jeremy that the current shape of the API is > too confusing. Maybe I can be useful as a new set of eyes. > > Looking at just this snip: > > function findFred(db) { > db.request.onsuccess = function() { > var index = db.request.result; > index.request.onsuccess = function() { > var matching = index.request.result; > if (matching) > report(matching.isbn, matching.name, matching.author); > else > report(null); > } > index.get('fred'); > } > db.openIndex('BookAuthor'); > } > > This example is hard to read where the callback is setup before the > call like this. Without making any API changes, I think you could > improve things: > > db.openIndex('BookAuthor'); > db.request.onsuccess = function() { > ... > }; > > You just have to make sure that the API guarantees that > onsuccess/onfailure will always be called in a separate event, which > is important anyway for consistency. > > I think it's counter-intuitive to have a single 'request' object per > database. Even though it might be technically true that in > single-threaded JavaScript that is the reality. A request describes > something that there are many of, that doesn't get reused. Reusing the > single onsuccess event also seems like something that is likely to > cause bugs (people forgetting to reset it correctly, an old callback > gets fired). Finally, developers might be used to XHR, where there are > of course multiple requests. > > So I think one improvement could be create one request for each logical request: > > function findFred(db) { > var req1 = db.openIndex('BookAuthor'); > req.onsuccess = function() { > var index = req1.result; > var req2 = index.get('fred'); > req2.onsuccess = function() { > ... > } > } > } > > Like I said, I've only thought about this for a moment. I know how > hard API design can be, and these are my drive-by first-blush > comments. But on the other hand, sometimes drive-by, first-blush > comments are useful for figuring out APIs. > > HTH, > > - a > - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuaf1gACgkQ9VpNnHc4zAwnQwCeMx2iLFEnUdBNiEfKoA339snl qSUAoKUfZBkLQkhzcN9GzFJF+i9TprvB =vUQ5 -----END PGP SIGNATURE-----
Received on Friday, 12 March 2010 17:53:58 UTC