W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [WebDatabase] Database interface (vs. DatabaseSync interface)

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 27 Jul 2009 13:54:59 -0600
Cc: Aaron Boodman <aa@google.com>, public-webapps WG <public-webapps@w3.org>
Message-id: <2AB1367B-DDA5-4EDE-B5CE-C7126C627A45@apple.com>
To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>

On Jul 27, 2009, at 12:55 PM, Nikunj R. Mehta wrote:

>
> On Jul 25, 2009, at 1:18 PM, Aaron Boodman wrote:
>
>> But using workers is a large burden: they are
>> completely separate JavaScript environments that share nothing with
>> the main web page. Having to use that for simpler use cases would be
>> very unfortunate.
>
> I am not sure how large a burden this is. Can you quantify it? Can  
> you explain why this would be unacceptable?

The cost of using a Worker is that all interaction with the actual Web  
page and its data is through an asynchronous channel that only allows  
transfer of relatively simple pure data objects (essentially, JSON).  
The advantage is that you can write database access as simple straight- 
line code. If you want to do a lot of database work and don't need to  
interact with page contents or associated JavaScript data structures  
in the middle or very extensively, a Worker using the synchronous API  
will likely work well. If you only want to do a little bit of database  
access, or you need to mix it heavily with page interaction, using the  
async API from the main thread will likely be simpler.

>
> The programming model espoused by WebDatabase's async portion is that:
>
> 1. the programmer does all the SQL work in one or more asynchronous  
> callbacks.
> 2. callbacks are always linear, however, the program performs its  
> own stack management to keep the requisite context around for doing  
> its processing inside asynchronous callbacks. If multiple calls to  
> the database are required to perform certain work, then the programs  
> become a chain of nested callbacks.
> 3. the only supported model of transaction isolation is  
> serialization of all database access.
>
> This is certainly foreign to most database developers. Editors and/ 
> or others share the burden of proof that there is no alternative to  
> this and that there is merit in standardizing a brand new  
> programming model.

JavaScript actually lets you write a series of nested callbacks in a  
way that looks almost like straight-line code, by using function  
expressions:

db.transaction(function(tx) {
     tx.executeSQL("SELECT UserID FROM Users WHERE UserName = ?",  
[userToBan], function(tx, firstResultSet) {
         if (resultSet.rows.length > 0) {
             tx.executeSQL("INSERT INTO BannedUsers VALUES (?)",  
resultSet.rows[0]);
         }
     }
});

(Sorry for the contrived example and my likely syntax errors.)

Granted, this gets awkward if your logic gets considerably more  
complicated.

Regards,
Maciej
Received on Monday, 27 July 2009 19:55:51 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT