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

Ashok: you have not marked your action PENDING REVIEW, but your note seems 
to merit telcon discussion?  Whether it gets scheduled for this week 
depends in part on whether I hear from you before the agenda is frozen, 
which >should< be in a few hours but may well take until evening, Eastern 
Time.  There are some other high priority items, so we may not get to it 
anyway, but I'll be glad to at least list it if you think it's ready for 
discussion.  Thank you.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








ashok malhotra <ashok.malhotra@oracle.com>
Sent by: www-tag-request@w3.org
02/23/2010 11:31 AM
Please respond to ashok.malhotra
 
        To:     "www-tag@w3.org" <www-tag@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        TAG Action-354 Review client-side storage API’s


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.

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.  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.

-- 
All the best, Ashok

Received on Wednesday, 24 February 2010 16:51:27 UTC