W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2007

[whatwg] executeSql API is synchronous

From: Aaron Boodman <aa@google.com>
Date: Wed, 8 Aug 2007 14:05:00 -0700
Message-ID: <278fd46c0708081405j6b587289u9671607c1f7d1915@mail.gmail.com>
FWIW, We (the gears team) considered adding an async version of our
sql execute() method, but decided against it in favor of improving the

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

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:36 UTC