W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: [IndexedDB] API feedback

From: Shawn Wilsher <sdwilsh@mozilla.com>
Date: Fri, 12 Mar 2010 11:13:51 -0800
Message-ID: <4B9A926F.3020509@mozilla.com>
To: Kris Zyp <kris@sitepen.com>
CC: Aaron Boodman <aa@google.com>, Jeremy Orlow <jorlow@chromium.org>, Nikunj Mehta <nikunj@o-micron.com>, public-webapps WG <public-webapps@w3.org>, Arun Ranganathan <aranganathan@mozilla.com>, Jonas Sicking <sicking@mozilla.com>
On 3/12/2010 9:52 AM, Kris Zyp 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.
Mozilla is *not* interested in implementing a synchronous API on 
anything but a worker thread.  Disk I/O timing is non-deterministic from 
the applications perspective (another app can be writing a bunch of data 
to disk making your reads/writes slow, or fsyncs from another app can 
flush out the entire disk cache on some file systems, etc).

With that said, I think providing a worker-only API is not ideal.  Not 
all browsers currently implement workers yet, and doing a worker-only 
API would exclude them.



Received on Friday, 12 March 2010 19:13:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:05 UTC