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
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 geocities.com, 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 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.
Having trouble installing and setting up Win10? You aren’t alone. Here are many of the most common...
Win7 Update scans got you fuming? Here’s how to make the most of Microsoft’s 'magic' speed-up patch
Picking an Android phone can be difficult, but we're here to help. These are the top Android phones you...
In fact, wait as long as Microsoft will let you, since this is mostly a minor upgrade
The demise of Visual Studio LightSwitch shouldn’t prevent power users from building line-of-business...
Google's container orchestration platform can now scale to massive clusters
IT expertise is no match for execs' stubbornness and agendas, even under dire circumstances