The Web's days of innocence -- where it was just used to post the digital equivalent of static brochures -- are long past. Today we expect to do everything over the web, no matter how forced and cludgy it has to work under the hood to accomplish our goals. Fortunately, there are people willing to wade into the mind-numbing realm of protocols and data streams in order to improve it all.
Taking Care of Data in Offline Web Apps
As web applications grow in sophistication, they're escaping the boundaries of constraints such as the web browser and the need to be constantly connected. The problem is that web standards such as HTML weren't developed for many of the use cases that are common with today's web applications.
Right now, everyone working on such applications has to develop their own solution. As work continues on the update toward HTML 5, parallel work is also in play to create standard protocols and APIs to prevent this constant reinvention of the wheel and faster innovation and easier interoperability.
One of the areas where, for the moment, people are having to hack solutions together is that of how to queue or cache data for a web application that has gone offline. HTML 5 offers a way to create application caches, but due to their static nature this option can only be used with safe HTTP methods. The Programmable HTTP Caching and Serving API is under development by the Web Applications Working Group to address this problem.
A Solution That Extends HTML 5's App Cache
This API extends HTML 5's application cache by:
- Allowing applications to add resources to the cache, which can then be served by the user agent when the resource is requested.
- Enabling applications to generate responses to requests for resources that were added to the cache.
These extensions allow use of the HTML 5 cache with unsafe HTTP methods like PUT and POST. As an example, the working draft offers,
Essentially, this extension allows web applications to seamlessly switch between online and offline work, causing far less hair loss as users will be less likely to lose their work due to a connection outage.
Those who want the absolute bleeding edge can check out the W3C Editor's Draft version of the API here.