Chrome OS's Secret Influence
When Google gave the first demos of its ChromeOS-based PC this week, there were only a couple of mentions of the new feature that's going to have the greatest impact on Web-based apps, or Web access of any kind, really, during the next few years: offline storage.
HTTP and HTML, the core protocols of the Web, were designed to not store information between browsing sessions unless the user specifically arranged to do it.
Cookies, browser caches and other performance-enhancers do store more data between sessions than you'd think (not always the embarrassing stuff, but certainly that seems to be the majority).
With current Web browsers, unless you purposely store a Web page to your hard drive, though, you're not going to have it after you relaunch the browser or reboot your machine.
That's both a usability and security feature, though neither is effective in that way now. The less data you store between sessions, the lower the chance malware or bad scripts will corrupt your data or apps. (See also Google CR-48: First Look at the First Chrome OS Laptop.")
Malware reproduces itself without needing the browser, though, and bad scripts will crash by themselves, blue-screen your PC, kidnap your children and paint rude things on your car no matter how little of them you keep resident on your hard drive
HTML5 was designed to let all those high-powered applications with Web-browser front ends work more effectively by giving them a place to store data on the hard drive where it can be reopened later, and a more flexible way to use the memory cache that Web browsers already depend on.
The idea is to make sure users don't lose the draft of an angry letter to the PAC of their choice, or the Google App documents they're working on when someone trips over the Ethernet cord or the WiFi cuts out.
Cookies work the same way -- storing coded information in secret folders in your browser directory. But HTML5 data isn't automatically sent to the sites you visit, and won't store on your hard drive unless you do both things on purpose.
There are actually two forms of storage built into HTML5 -- local and Web. Web storage works in exactly the same way as local except for the addressing -- if you're not a programmer who needs to code in the difference between the two -- so we'll stick with local for now.
It doesn't store data as straight text, MS Office documents or other familiar forms, though. It stores them as a series of keys and the values with which they're associated.
That doesn't make much difference to non-programmers, but if you go looking for the data itself, hoping to find a raw .txt copy of your Gmail note, don't be surprised if you find something that looks more like the Windows Registry.
It associates all the offline data with the Web site it came from, though, which makes it much easier to find if you're using a site like Google Apps, that you come back to frequently, but less so if it's a site whose name you forget if you don't recognize the icon on the bookmark.
All this is controlled by the User Agent -- part of the browser that takes care of data storage and housekeeping and security. It creates a Storage Object for each document you want to save, which links to the key/value pairs the software recognizes as the good data.
Google Gears was supposed to do a lot of the same things, until Google dropped it late last year in favor of HTML5. Silverlight did it for a while, but Microsoft is moving away from that in favor of HTML5, too.
Flash has been in that position for a while, but is on the way out. HTML5 was billed early as a Flash killer. Apple hates it and uses HTML5 instead. Flash is slow compared to proprietary approaches like Gears and Silverlight, and all the competing software vendors figure it's easier to support HTML5 than fight.
Apps that use HTML5 can use the data however they want. A "connection-proof" link to a server-based app would sync data with the server, but store everything locally as well so you wouldn't lose it if your connection went poof.
Depending on how developers set up the app you should be able to pick where and (within limits) how your offline data are stored.
HTML5 specs require that the User Agent not delete data without the user's say-so, so in general your documents are safe. Server-based apps can be set to override that and copy over or delete older data, however.
OK, I lied. There is a difference between local and Web storage.
Mainly it's that documents stored online have to be stored in a beefier database -- usually a Web SQL thing -- rather than within the browser itself.
App developers can write to those fairly easily to do two-way data synchronization or downloads, though, so from a user point of view there's not much difference except for which you can access when you're not connected.
OK, there's one more type of offline storage in HTML5, too. App caching.
Like prefetch in Windows, Application Caching is supposed to make applications run faster by downloading the software itself into a chunk of memory on your computer and then saving it to a separate section of your offline storage cache.
If the cache is for a game site that you revisit, the Java code, CSS, icons, images, sounds and other data that's a part of the game would load immediately because they're sitting on your hard drive and don't have to download.
Most browsers can do that now, but the caches into which most of that data are stored can be overwritten so you have the Java but not the CSS, the CSS but not the sounds or settings, which either confuses the software so it crashes or forces you to download the whole thing again.
When Will it be Available?
It's available now, mostly.
Analysts said HTML5 will start out in pretty much the same niche as Flash -- doing games and light aniimation or coding of local apps. It is capable of supporting much more powerful code, but won't get into serious transactional or other highly secure, critical business applications for another couple of years.
There are already plenty of games and video available for playback using HTML5. More than half of all Web video can be replayed using HTML5, according to a study by MeFeedia, compared to 10 percent in January -- an increase analysts peg to high sales of the HTML5-using iPad.