On 3/12/2010 9:52 AM, Kris Zyp wrote:
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).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.
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.
Cheers, Shawn
smime.p7s
Description: S/MIME Cryptographic Signature
