HTML5 in the browser: Local data storage

HTML5 Web Storage, Web Database, FileReader, FileWriter, and AppCaching APIs will transform Web pages into local applications, but not yet

Page 2 of 5

The persistence goes deeper. Two windows visiting the same website should share the data. A change by the code running in one window should change the data accessed by the other. As the spec says, a storageChange event in one window should propagate to all windows. (This isn't always the case. In some browsers sessionStorage isn't shared between tabs, while in others it is. The edge conditions are not set. The sharing of localStorage and sessionStorage is not perfectly implemented yet.)

There's been some debate over how tightly to limit connection to this object. Right now only scripts from the same scheme, domain, and port are allowed access. This is pretty strict and prevents any confusion that might come about when people load common scripts or switch between HTTP and HTTPS.

While this sounds like a dream for many Web programmers, there's the very distinct possibility that it could cause nightmares because it's easy for two windows to access the same data and create a race condition that corrupts the data. There's a great deal of debate over whether the storage object should defend against this by implementing a mutex (a mutual exclusion algorithm) that can limit data corruption.

One recent draft notes, "The use of the storage mutex to avoid race conditions is currently considered by certain implementors to be too high a performance burden, to the point where allowing data corruption is considered preferable. Alternatives that do not require a user-agent-wide per-origin script lock are eagerly sought after."

This probably won't affect many of the simplest uses of the object, but it could easily produce bizarre errors when people leave several windows open. I often leave Web mail windows alive on my desktop, then open another instance because I'm too lazy to dig through the pile of windows and tabs. Programmers must be aware that different instances of their code will run in the same browser, and this code will have access to the same data.

Note this quote from the spec: "Different authors sharing one host name, for example users hosting content on, all share one local storage object. There is no feature to restrict the access by pathname."

How much room do you get? Can you count on having enough room? Is there a way do defend against DNS spoofing? For all of the questions that localStorage answers, it creates many more.

Web SQL Database and IndexedDB
The key-value pairs in the localStorage object are usually powerful enough for many basic projects, but they're not comparable to relational databases that store the information in indexed tables. For that, there are not one but two options.

The first, the Web SQL Database standard, was drafted and implemented before being abandoned for a more abstract version. People using WebKit browsers and Opera will find that a small database engine, SQLite, was grafted onto the JavaScript engine to let people create tables and store rows using all that knowledge about SQL.

The work, though, was for naught because the committee decided it wanted something else. While the features are still available in the supporting browsers, the Web database standard is now filled with language designed to scare people away. "Beware," it warns. "This specification is no longer in active maintenance and the Web Applications Working Group does not intend to maintain it further."

The new king is the more abstract idea of the Indexed Database, an SQL-free pile of keys and values just like the localStorage object. The difference is that an index can speed finding the necessary object. In practice, this seems to mean that the browsers will store each table in a B-tree to speed lookup and allow the programmer to page through the data in some repeatable order.

| 1 2 3 4 5 Page 2