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 <[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
