Improving ApplicationCache for Real World Web Apps

Author: Peter Lubbers, Senior Director of Technical Communication, Kaazing

Background and Bio:

My name is Peter Lubbers. I co-authored the book Pro HTML5 Programming (Apress, 2010, with a chapter on Application Cache) and I started the San Francisco HTML5 User Group. In the last year, I have given presentations about building offline web applications at HTML5 User Groups in San Francisco, New York, Paris, and London. Finally, I am writing this proposal in a Mozilla T-shirt that I received for helping with a substantial rewrite of the MDN article about Application Cache ;-)

In your call for participation, you mention, "the current fragmentation in the solution space is creating confusion among would-be WebApp developers and organizations who would otherwise invest in the Open Web Platform." That is a very good point and a situation I would like to avoid and with a focused effort I think we can achieve this.

In the last 18 months, in my job as an HTML5 Trainer, I have been acting as somewhat of a tour guide, helping more than a thousand training attendees (from companies small and large) through the minefield of creating offline web applications for today's desktop and mobile browsers.

I have run into countless quirks and although browser support has come a long way in a short period, there is still more work to do. I am very excited about the promise of HTML5 Offline Web Applications and would love to have the opportunity to help shape their future. I am ready to help in any way I can!

I think I can safely say that the number one problem developers face when they first deploy their offline web applications is that the manifest (*.appcache files) is not served with the right mime type. At the company I work for (Kaazing) we build a WebSocket server that doubles as an HTTP server. To speed up adoption of offline web applications, we have tried to do our share in terms of evangelism, but we have also implemented proper mime type serving for *.appcache and *.manifest files (text/cache-manifest) to speed up adoption of the offline web app standard.

Position, Suggestions, and Request for Clarification:

There are several ApplicationCache areas for which I would like to propose some improvements and clarification:

• Quota Management Going over quota in today's browsers is hard to deal with as a developer. We need a proper API similar to WebKit's window.webkitStorageInfo that can be called prior to writing to the cache. I don't think there are plans to use that particular API for ApplicationCache, but I don't see why it could not be used so propose that we look into that.

In addition, I would suggest that on-the-fly over-quota handling with user interaction is implemented by all browsers in the way that Opera has currently implemented it for LocalStorage and I can provide screenshots or a live demo of the proposed quota management behavior during the workshop.

• Development of a Test Suite, Examples, and Test Applications. I have created training curriculum for creating offline web applications and Kaazing is willing to contribute parts of that to the community to make it easier to test offline web apps. I can also provide the results of lots of (manual) browser compatibility testing for more granular browser support of parts of the spec beyond simple ApplicationCache support (for example, how do different browsers handle Fallback content, server disconnects, and so on). I can demo the test pages and test script during the workshop.
• Additional Cache Control I would like to propose the possibility to flag a file that contains the manifest reference to *not* be cached (This is not currently possible and a show stopper for many). Allowing this would make it possible to cache resources like CSS/JS/Images, without caching the actual page itself.
• Spec Clarifications There are a number of areas in which the ApplicationCache specification is not entirely clear and I would like to address those areas in an effort to improve browser interoperability (one of the HTML5 design goals). These areas include, but are not limited to: a) What happens to the caching behavior when you navigate away from a page while resources are being cached? b) Do we need to use the same-origin policy over TLS or can Cross Origin Resource Sharing (CORS) be used somehow to relax this policy if it is needed? c) What are the best practices around NETWORK resources?