W3C home > Mailing lists > Public > www-tag@w3.org > February 2010

Re: TAG Action-354 Review client-side storage API’s

From: Dan Connolly <connolly@w3.org>
Date: Wed, 24 Feb 2010 11:03:12 -0600
To: ashok.malhotra@oracle.com
Cc: "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <1267030992.30230.207.camel@pav.lan>
On Tue, 2010-02-23 at 08:31 -0800, ashok malhotra wrote:
> My earlier note on this action is at 
> http://lists.w3.org/Archives/Public/www-tag/2010Jan/0008.html
> 
> On the Feb 5 telcon I was asked to do some more work on ACTION-354, 
> partly to respond to Mark
> Nottingham -- 
> http://lists.w3.org/Archives/Public/www-tag/2010Jan/0077.html --
> who asks "I think the key question here is what the relationship of 
> these new proposals to existing ones;
> the Web already has caching, and it already has stateful cookies (both 
> of which, BTW, are currently
> being revised in the IETF)."
> 
> As I said in my earlier note, there are two drafts that replace/extend 
> cookies. 
> Web SQL Database <http://dev.w3.org/html5/webdatabase/>
> Indexed Database API <http://dev.w3.org/2006/webapi/WebSimpleDB/>
> I asked Ian Hickson, the author of the first of these drafts the 
> rationale behind them.  Ian replied:
> "Cookies are unreliable, sent to the server, have a small quota, and 
> have a terrible API. Web Storage is intended to fix that.
> 
> Web SQL Database, Web Storage, and the new Indexed Database ... have more or less the same use cases, except the database versions are intended for more structured indexable and queryable data. For example, consider GMail going offline. You want a highly 
> structured data store. Obviously cookies aren't going to cut it if you 
> have gigabytes of mail."
> 
> The other spec we discussed on the Feb 5 call was Programmable HTTP Caching and Serving <http://dev.w3.org/2006/webapi/DataCache/>
> The rationale behind this is easier to figure out. Essentially, it allows modification of the cache under program control (adding/deleting values).  It allows the cache to be
> shared across multiple browser windows and it allows the cache to be used while the user 
> is offline.

So far so good...

> Some feel that to enable real applications to be run from the browser you need to
> be able to work with a database.  The two specs discussed above facilitate this but,
> in my personal opinion, do not go far enough.  It seems to me that what you need is
> the ability to run SQL queries from Javascript.

You lost me there; doesn't Web SQL Database provide exactly that?
The examples certainly suggest it:

db.readTransaction(function (t) {
  t.executeSql('SELECT title, author FROM docs WHERE id=?', [id], function (t, data) {
    report(data.rows[0].title, data.rows[0].author);
  });
});

>   The SQL queries could be identified
> by URIs.  The result is then packaged in a suitable form and sent to the client where
> it is unpacked and added to the application cache.

"sent to the client"? The data is already on the client in these use
cases, no? The subject of this thread is "client-side storage".


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
Received on Wednesday, 24 February 2010 17:03:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:19 GMT