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

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.


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]             
> [2]   [3][4]
> [5]
> [6]
> [7]
> [8]
> [9]
> [10]
> [11]
> -- 
> All the best, Ashok

Mark Nottingham

Received on Wednesday, 20 January 2010 23:19:10 UTC