- From: Aaron Boodman <aa@google.com>
- Date: Fri, 12 Mar 2010 10:33:38 -0800
- To: Kris Zyp <kris@sitepen.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>
On Fri, Mar 12, 2010 at 9:52 AM, Kris Zyp <kris@sitepen.com> wrote: > 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. No, I think that is a non-starter. Doing synchronous IO has been explored before in other APIs and thoroughly abandoned. I don't feel like looking up a link now (you can probably do a search on the whatwg archives for 'synchronous'), but basically: * Disks can get busy, so even if an operation is *normally* fast, it won't always be * Disks can be remote, mounted over a network - a
Received on Friday, 12 March 2010 18:34:08 UTC