FWIW, We (the gears team) considered adding an async version of our sql execute() method, but decided against it in favor of improving the workerpool.
Async APIs work OK for a few requests, but a single logical update to a local database might be made up of many SQL statements. Stringing these all together with async APIs is a big pain, especially if results must be passed between the statements. A background worker allows you to express long strings of database logic in simple synchronous code. You can even intermingle _synchronous_ httprequests between the database operations. So synchronization logic, for example, turns into simple looping code. - a On 8/8/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > http://www.whatwg.org/specs/web-apps/current-work/#executing > > The executeSql() API returns a result synchronously. In general, SQL > databases may be slow to access since they need to be read from disk, > and if the database is not open already there's unlikely to be a ready > cache. This may make it hard to use the executeSql() API without > blocking the UI. All other HTML DOM operations that may require I/O to > complete are asynchronous, with the exception of synchronous > XMLHttpRequest which (a) causes UI lockup problems in practice and (b) > at least has an async variant. > > The original Google Gears API that inspired executeSql gets around > this by providing a threading facility, so that worker threads can do > all the database access. > > I think to make it possible to use executeSql without risk of harming > interactivity, we need either an async version, or a worker thread API. > > Regards, > Maciej > >
