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

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

From: ashok malhotra <ashok.malhotra@oracle.com>
Date: Wed, 24 Feb 2010 09:34:57 -0800
Message-ID: <4B856341.80903@oracle.com>
To: Dan Connolly <connolly@w3.org>
CC: "www-tag@w3.org" <www-tag@w3.org>
Hi Dan:
My understanding is that the Web SQL Database spec is stalled because it 
is based on the SQLite product
and needs a second implementation to advance.

The last para is not strictly part of the action.  Just my thinking out 
loud.  We can discuss offline if you wish.
All the best, Ashok


Dan Connolly wrote:
> 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".
>
>
>   
Received on Wednesday, 24 February 2010 17:35:47 GMT

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