[whatwg] executeSql API is synchronous

[Aaron Boodman]

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