- From: Nikunj Mehta <nikunj@o-micron.com>
- Date: Sat, 13 Mar 2010 01:15:38 -0800
- To: Kris Zyp <kris@sitepen.com>
- Cc: Aaron Boodman <aa@google.com>, Jeremy Orlow <jorlow@chromium.org>, Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps WG <public-webapps@w3.org>, Arun Ranganathan <aranganathan@mozilla.com>, Jonas Sicking <sicking@mozilla.com>
On Mar 12, 2010, at 9:52 AM, Kris Zyp wrote: > -----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)? This is entirely plausible. It is also the reason I have temporarily tuned out of most async API questions around IndexedDB. > 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). I know that with Berkeley DB, operations are performed in practically constant time since the base of the log is pretty high - something like 4000. So for all practical purposes, the processing time would be very low. In fact, I can hypothesize that the JavaScript context switching and event queuing will cost more than the I/O. > 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. As I indicated in a previous email, the search for a good async API should not block progress on the rest of the API. > 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 Saturday, 13 March 2010 09:17:24 UTC