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. Cheers, Shawn
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:05 UTC