views:

324

answers:

2

While there are a lot of good stuff about html5, one thing I don't get is the redondant storage mechanism, first there is localstorage and sessionstorage, which are key value stores, one is for one instance of the app ("one tab"), and the other works for all the instances of that application so they can share data. Both are saved when you close your browser and have a limited size (usually 5MB), that's great and everything would be nice if we stopped there.

But then there is the "Web SQL Database", which has the same security system as the localstorage, the same size limit, the same everything except it works like/is sqlite, with tables and sql syntax and all of that.

And the bummer is, they don't work on the same data at all ! This is not two way to access your data, this is really two storage for every html 5 app out there (not created by default yes, but still you see my point).

What I would like to know is, is there a reason for both of this mechanisms to exist at the same time ? Or did they just look at sql and nosql movement to pick the best then went "screw it let's add both !" ? Why not implement local/session storage as a table inside web sql db ?

+4  A: 

My take is that localstorage is a proper rewrite of the way cookies should have been done in the first place. It has a very simple api and low barrier to adoption.

Web SQL is pretty heavy duty and would be a serious pain for saving just a simple value so they have very different use cases. localstorage is actually implemented in WebKit using SQLite but just not exposed via WebSQL.

Session storage cannot be implemented easily inside the database as it is effectively in global scope and you don't want the data visible to other tabs. Because it is transient data you wouldn't typically want to store lots anyway so wouldn't need transaction and querying.

See also: http://www.pubbs.net/200904/webkit/28373-webkit-dev-need-help-making-windowlocalstorage-span-processes.html

Brendan Heywood
A: 

I asked myself the same question, and here is the answer, quoted from the Chromium wiki :

Q: Why this over LocalStorage?

A: LocalStorage is inherently racy or a parallelism disaster, depending on whether or not you're willing to implement the "storage mutex" described in the spec. Chromium has decided not to implement it. WebKit itself is single thread/process (i.e. no parallelism period)

Source : http://www.chromium.org/developers/design-documents/indexeddb

Web SQL can be useful if you want to copy the structure of your database locally for offline use.

But Web SQL will not be implemented in firefox : http://us1.campaign-archive.com/?u=168bf22f976f5a68fe5770d19&id=6c2d73c957#standards

Mozilla, Microsoft and Oracle are working on the "IndexedDB" alternative : http://www.w3.org/TR/IndexedDB/

Work in progress in firefox : https://wiki.mozilla.org/Firefox/Projects/IndexedDB

Storage demos :

ideotop