[whatwg] executeSql API is synchronous

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

Received on Wednesday, 8 August 2007 14:05:00 UTC