Client Side Storage and Caching
From RuntimeWiki
NOTE: This feature has been moved to the inactive list because latest browsers already are addressing this by implementing HTML5 client-side storage
Contents |
Title
Improved Client Side Storage and Caching
Detailed write-up
Description
Current browsers offer very limited support for client side storage and caching:
- Extremely limited client side storage: currently this is only possible via “cookie”, which is limited to a few kilobytes;
- Caching: browsers typically cache web pages, but web developers have very limited control of what and how.
As web application grew in complexity, the need for improved client side persistency and caching grew significantly. Web developers need:
- Larger client side storage capacity. Some of the competing technologies such as Flash offer 100KB client side capacity by default, and provides developers support for seeking user permission for larger storage capacity. Similar behavior would be helpful for web applications too.
- Better control of client side caching. With an increased storage capacity and API support for seeking additional storage, developers can cache web application content on their own, without having to rely on the browser’s default caching behavior.
Why Is This Important?
Web applications have grown in complexity significantly comparing with ten years ago. At that time, solutions like cookie and default browser caching behaviors were sufficient. However:
- The user experience expectation of web applications has grown significantly. We used to expect “click, wait and refresh”. Now we expect “desktop-like performance” for browser applications;
- The footprint of web applications has grown significantly, especially Ajax applications. It is typical for web sites to download 100KB+ of JavaScript nowadays. For more focused applications, the amount of JavaScript required for downloading can be as higher as over one megabyte.
- The amount of data that applications are handling also increased significantly, in particular, data on the client side.
The net result is that we have a growing gap between the need for better performance/less number of network round trips vs. increased amount of download footprint and client side data. Client side persistency and caching holds a key to bridge this gap.
What exists today
(People who know about what exists in which browsers, please fill out this section. Here is some partial information)
HTML5:
-
window.sessionStorage: key/value (string) storage shared between pages from same domain and using same window -
window.localStorage: key/value (string) storage shared between multiple windows and persists beyond current session -
window.openDatabase(): create an SQL database for use by Web pages from the current domain - 'storage' event is fired whenever session storage or local storage changes
Latest browser support:
- IE8 - Supports
window.sessionStorageandwindow.globalStorage(which appears to be a different name forwindow.sessionStorage) and fires the 'storage' event. No mention of support forwindow.openDatabase(). - FF2 and FF3 - Same features as IE8
- Safari 3.1 - ???
- Opera - ???
Possible Solutions
Again, we are looking for a solution that can be implemented relatively easily by browser vendors without another W3C standard. Here are some suggestions:
- Increase the default client side storage limit to 100KB;
- Provide an additional API for developers to control whether a “cookie” should be send back to the server.
- Provide an API for developers to ask user permission for more storage capacity;
Background material that request this feature
Discussion
Jon Ferraiolo's comments
Google Gears is a great start for defining technology for allowing a whole new level of client-side storage and caching. It goes well beyond increasing the size of data that can be stored to provide an SQL engine for storing that data. It also takes caching to the next level where particular URLs can be flagged as requiring a more permanent caching to the point where those URLs can be run even when the user is disconnected from the Internet. This technology is probably sufficient even today, but will improve as Google's products adopt this technology and fixes are added. On the standardization front, Gears has been submitted into the WhatWG and HTML, which means a straight hand-off to the W3C for formal standardization. (NOTE: I am not an employee of or any sort of agent for Google!)
However, there are technical reasons and business reasons why other browsers might be reluctant to adopt Google Gears as it stands today, either as defined by Google specs or within the HTML5 drafts. I am not an expert here, but my understanding is that WebKit has included features that overlap (and have been informed by) Gears, but which differ in various ways. One could imagine that Microsoft's IE team might find reasons why they do not want to implement Gears from Google specs or open source, or from any WhatWG specs (e.g., due to lack of an IP policy).
Therefore, here is what I would propose to the browser vendors. Either implement Gears or implement something that provides many of the same services with different APIs, so long as it is possible for an Ajax library can provide a single API to Ajax developers that can map to the different APIs that the various browsers provide. Dojo Offline Toolkit (http://dojotoolkit.org/offline) is one example of an Ajax library that sits on top of Gears. If a browser does not want to support Gears APIs as currently defined, then one option is to find a way to plug into Ajax libraries such as Dojo Offline Toolkit. If the browser vendors are looking for a forum where they can collaborate on this "Ajax approach" to offline and caching, I'm sure OpenAjax Alliance would be willing to help.
Phase I Voting - Vote for Your Top 5 Features
NOTE: PHASE I VOTING IS NOW OPEN. (2008-04-01) We have now changed the voting procedure. Instead of putting votes on each separate wiki page, we are asking people to cast their Phase I Votes on the following wiki page:
Phase II Voting
More about this later.
