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