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

[whatwg] executeSql API is synchronous

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 8 Aug 2007 13:36:43 -0700
Message-ID: <36A791DE-1801-47E9-9B11-FAB1C517F8A6@apple.com>


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.

Received on Wednesday, 8 August 2007 13:36:43 UTC

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