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

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

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 21 Jan 2010 10:18:39 +1100
Cc: <www-tag@w3.org>
Message-Id: <94C52C93-BBC3-421C-B7A5-AF84AFAA35B8@mnot.net>
To: Ashok Malhotra <ashok.malhotra@oracle.com>
From a Web architectural standpoint, 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). 

Defining these as client-only, API-centric extensions from whole cloth implies a whole raft of architectural decisions that should be made explicitly.

Cheers,


On 06/01/2010, at 1:09 AM, Ashok Malhotra wrote:

> TAG Action-354 Review client-side storage API’s
> Introduction
> Originally there was a section in the HTML5 draft that specified a client-side database interface.  This was split out into a separate draft.  It has now morphed into two drafts, quite different in style and capability under the aegis of the Web Apps WG.  [1],[2]
> The requirements for client-side storage are not very crisp [3].  In addition to cookies on steroids, the following requirements seem reasonable:
> ·  Off-line accessible: Client storage should be accessible by a client-side web application even when the client cannot contact the server from which the data was loaded.
> ·  Secure: Client-side web applications are identified by the URL they were loaded from.  A client side web application is only able to access storage associating with a matching domain and path. (Like cookies.)
> ·  Controlled transmittal: Unlike cookies, local storage need not be transmitted to the server on each HTTP request. Instead applications can send *selected* client data to the server under program control.
> Web SQL Database [1]
> Web SQL Database presents a SQL-like interface for storing and retrieving client-side data.  I say SQL-like because it is not SQL or even a subset of the SQL standard.  It is based on a specific product called SQLite – the text says “User agents must implement the SQL dialect supported by Sqlite 3.6.19.”  It seems curious to write a standard based on specific software  product .  An argument has also been made that multiple uses of SQLlite by vendors do not constitute independent implementations.
> In point of fact, SQLite does not support a “dialect of SQL”, it is fundamentally different in a significant way: it supports weak, dynamic typing rather than SQLs strong static typing.
> Another question worth asking is whether the functionality of SQL is needed for a facility to store and retrieve name-value pairs. Even if the browser vendors don’t have to implement the function it does bloat the linked libraries.
> In response to arguments such as the above and others  See [4],[5], an alternate client-side storage specification called Indexed Database API has been developed.  On the other hand, a couple of browser vendors claim to have implemented Web SQL Database [6],[7].  Note that Google Gears uses SQLite.
> Indexed Database API [2]
> This used to be called WebSimpleDatabase but the new name seems better as it reflects the capabilities which offer indexed storage for name-value pairs.  Databases can be created to store sets of key-value pairs.  The value can be an object with properties.  Indexes can be created on any of the value properties for efficient retrieval.  A key-value record is retrieved by making an API call that either iterates over a range of keys in the object store or by identifying the key corresponding to the required record.
> Status
> Both WebSQLDatabase and Indexed Database API are at WD stage   Philippe requested an analysis for the various storage APIs.  A Wiki with analysis is at [8]. 
> Bottom Line
> It would be unwise to have more than one standard for client-side storage.  There seems to be a technical preference for Indexed Database API over WebSQLDatabase but some vendors have implemented WebSQLDatabase and are getting ready to ship.  See [9]. The Indexed Database API is referred to by the first name of the author: Nikunj.
> Meanwhile, Ian Hickson has asked for the WebSQLDatabase spec to be taken to Last Call [10].  There is, however, a subsequent thread on “parking” WebSQLDatabase by publishing it as a WG Note [11].
>  
> [1] http://dev.w3.org/html5/webdatabase/             
> [2] http://dev.w3.org/2006/webapi/WebSimpleDB/   [3] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0303.html[4] http://www.w3.org/mid/63df84f0909011636x6ce5327ds241032a3b7080fe1@mail.gmail.com
> [5] http://www.w3.org/mid/C84F9222BE3A34439A7F58655086DFD70CD9896DE0@AA-EXMSG-C426.southpacific.corp.microsoft.com
> [6] http://webkit.org/blog/126/webkit-does-html5-client-side-database-storage/
> [7] http://lists.w3.org/Archives/Member/chairs/2009JulSep/0046.html
> [8] http://www.w3.org/2008/webapps/wiki/Database
> [9] http://www.w3.org/2009/11/02-webapps-minutes.html#item11
> [10] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/1121.html
> [11] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0526.html
> -- 
> All the best, Ashok


--
Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 20 January 2010 23:19:10 GMT

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