[whatwg] executeSql API is synchronous

[Maciej Stachowiak]

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