This is a group for coordination between developers in the broader community, browser vendors, and specification writers about addressing the existing issues with Application Cache.
This group is now closed; see http://lists.w3.org/Archives/Public/public-fixing-appcache/2013Feb/0005.html
Group's public email, repo and wiki activity over time
Note: Community Groups are proposed and run by the community. Although W3C hosts these
conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
A lot of things happened in AppCache land since this group was revived late last summer.
The meetings organized in London at FT Labs (minutes) and at Mozilla’s HQ in Mountain View (minutes) helped with two things:
scope the precise nature of the problem with the current AppCache spec. It turned out that this had much more to do with serious API flaws (mainly, the conflation of routing and caching APIs) than unclear or unmet use cases and requirements.
get consensus among browser vendors that this was a problem worth solving.
In November 2012, during TPAC, the WebApps WG agreed to take on authoring of a new version of the spec (minutes).
Since then, Mozilla and Google have been actively working on two different propositions which they started socializing during an informal meeting last week in Google’s London office (minutes) and during the offline panel at Edgeconf this saturday. Unfortunately, neither proposition is public at the moment, but I’m hopeful this will be addressed shortly.
Formalizing the case studies and use cases collected through our previous meetings by publishing a document seems rather moot now that we’ve identified the problem as being related to API design. Also, it would require work no one seems to have the bandwidth for at the moment.
This CG not being chartered to work on the actual API (that’s for the WebApps WG to do), CG participants who wish to have a say in how the API is designed should do so within the WebApps WG directly. The API changes considered are such that use cases fulfilled will probably be much broader than what we’re currently looking at. Because of that, I also feel they’d be best discussed within WebApps.
Keeping this CG alive seems artificial at this point and I suggest we kill it.
Best,
—tobie
Note that I’ve archived the minutes of all three meetings in the wiki for future reference.
UPDATE February 15, 2013: As there were no objections the chairs pronounce this group closed. See in you in WebApps WG to build the next version of AppCache.
Needed a place to dump AppCache use cases we (Facebook) felt the current Working Draft and Editor’s Draft didn’t address so I could reference them from the relevant entries in the HTML5 bug tracking system.
For references, these are:
#14701 – appcache: remove the requirement for the MIME type
#14704 – appcache: allow a manifest to be identified by something other than its URL
#14705 – appcache: SOP requirement for cache manifest files should be relaxed (at least) by CORS.
The following are use cases and are not intended as Contributions under the CLA.
Make a blog work offline
A blog engine (e.g. WordPress) can have a very basic offline mode that caches its index page and the _n_ entries listed on it for offline use. This wouldn’t modify its behavior when online, so that visiting the index page would always display the last entries and not need a page refresh to do so.
Allow an application hosted on a cluster of servers to be easily updated
An application is hosted on a cluster of servers behind a non-sticky load balancer. It is updated daily. Even though all servers are not updated instantly and two versions of the application co-exist for a while, it is possible to update the application without risking to have an out-of sync version of the application (e.g. manifest file and assets of the latest version combined with a Master Entry of the previous version) or to need to invalidate the cache to avoid such issues.
Defer or prevent the automatic update of an application
An ajax-heavy application, used largely in remote regions where connectivity is spotty, would be able to defer or prevent automatic update of AppCache so that it doesn’t interfere with the application’s own networking needs.
Prevent sensitive data from being cached
A website containing both public and sensitive HTML pages needs to be made available offline. The sensitive data must not be stored on the device. The website is hosted on a virtual host and HTTP headers cannot be modified. The web developer can prevent such pages from being cached by specifying them directly in the manifest.
Avoid polling the manifest file on each page load
An application used essentially while traveling abroad wants to reduce its number of requests to a minimum (so avoiding unnecessary calls to the manifest file every time it is loaded). However, it would still need to be patched immediately when an update is available. How the app becomes aware of the availability of an update could be through various means: a custom HTTP header or a cookie passed during an Ajax request, through a custom UI when the user is on Wifi, etc.
Programmatically busting the cache
While developing an offline application, a developer can easily bust the cache through the browser’s console.
Arguably, some of these use cases might be better handled at the OS level. It might be useful to hint at those through non-normative sections of the specification.
