[whatwg] Why SQL? was: Comments on updated SQL API

[Ian Hickson]

On Mon, 24 Sep 2007, Andrew Fedoniouk wrote:
> > >
> > > I have a question: why SQL was chosen as client side storage for Web 
> > > Applications?
> > 
> > Because it's what most app developers are already used to -- the M in 
> > the widely used traditional LAMP stack is SQL.
>   
> "most app developers are already used to" ... do what?

Storing structured data in SQL databases.


> I understand need of SQL DB on the server but data on the client has 
> different structure as a rule.

Actually the primary use case for this is offline applications caching 
server data on the client, where in fact the data ends up being exactly 
the same data as on the server. I expect many authors will end up merely 
replicating their schema on the client, in fact.


> Do you know any example where client storage as SQL DB is *really* 
> needed?

Almost any offline application, like offline Web mail systems, would be a 
good example. Given the demand for the feature (so much so that, e.g., the 
Google Gears team prioritised it to being one of the first three things to 
implement as browser extensions), I have no fear that this is something 
that few people will find useful.


> And by the way what flavor of sql is used? Transactions, stored 
> procedures / triggers ? Or we will declare that we all should have to 
> use SQLite only? (I have nothing against SQLite per se - it is good)

My intent is to await implementation feedback on this matter. SQLite seems 
like a good starting point, though.


> Some particular company may find that for their particular tasks SQL is 
> exactly what is needed but I do not think that it is wise to assume that 
> all storage needs will fit in procrustean bed of SQL/ relational DBs

Indeed, that's why we have a variety of other storage solutions like the 
globalStorage and sessionStorage APIs, cookies, server-side storage, etc.


> and all UA vendors will agree to use the same version of SQLite.

Different browsers will always be at different levels of development. Once 
we (the Web community) have more experience in this field, we can define a 
common set of functionality that all UAs must support, much like we do 
with all other features.


> I suspect that initial simple *Berkeley DB* alike proposal is what 
> really needed and enough in most cases.

It's possible. However, most implementation feedback at this point has 
encouraged us to follow an SQL route.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'