- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 8 Aug 2007 16:46:49 -0700
On Aug 8, 2007, at 2:05 PM, Aaron Boodman wrote: > 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. Sounds like worker threads might be a better solution, but either way I think the spec should address this. Regards, Maciej > > > - a > > On 8/8/07, Maciej Stachowiak <mjs at apple.com> 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 >> >>
Received on Wednesday, 8 August 2007 16:46:49 UTC