Last modified: 2014-05-06 21:29:33 UTC
I'd like to suggest implementing HTML5 caching manifests, so that supporting browsers could permanently cache resource files (HTML/CSS/JavaScript/image) used by Mediawiki. Since implementing caching manifests would not be sufficient in itself to create an application to work wholly offline (such as outlined in bug 28706), this step would be for the sake of improving performance and lowering demand on the server, but could facilitate any future steps toward caching content as well. After the first time obtaining copies of such resource files, browsers would never need to ask Wikipedia again for new copies, except for occasionally pinging Wikimedia servers (when online) to check whether there were any updates to those files that needed to be auto-downloaded. Browsers of course currently do cache Wikipedia files, but they don't reserve permanent space in the browser for these files, so the browser will periodically need to re-download these files and thus slow down their visits and demand on the server. Browsers may impose size limits on the amount of memory that can be used by a given domain for resource file caching, or require permission when beyond a specific size, so the user experience or availability may differ slightly based on the browser. Documentation on manifests are here: http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html
I don't think App Cache would play very well with ResourceLoader...
Why? Are the cache manifests not adequately dynamic? If this is based on experience, might you share your insights with WhatWG so the standard can be improved so as to accommodate your needs? It should I would imagine be possible to somehow and eventually work things out...
Is there a bug open for a hook to add attributes to the HTML tag? (I can't find one.) I mean, something like OutputPageHtmlAttributes, so that the manifest tag can be added?
Like I mentioned on the mailing list, ApplicationCache is meant specifically for single- or few-paged offline web applications. It will cache all pages permanently until the cache manifest is changed. MediaWiki is *not* few-paged and is instead focused around separating content across individual pages. This is specifically addressed by the standard in section 6.7.1.1 from the link in comment #0. Unfortunately, even there the exact implications of the prefer-online caching mode are not well documented. Also, as Brion mentioned, this would definitely not play well with ResourceLoader, especially since it is already using two different layers of caching (the browser cache and the LocalStorage module cache). I'm assuming the ApplicationCache layer would have to fit in between those two layers.
Well, Application Cache can be used as part of making a "look up stuff" site like Wikipedia work offline. Though it does take an iframe hack and a bunch of wrestling: http://alistapart.com/article/application-cache-is-a-douchebag
ApplicationCache--assuming the difficulties of your integrating with ResourceLoader could be overcome--can still be of use: 1. By utilizing a permanent cache, resource files don't need to be periodically redownloaded (e.g., if the browser auto-deletes its regular cache). It could optimize performance and minimize server requests (though browsers would periodically try pinging to see if the cache manifest file itself had been updated). In other words, the whole site doesn't need to be cached; appcache caches only those files designated, so appcache can be used even in environments not meant to go completely offline. 2. In combination with my proposed functionality in bug 45981 , users would be able to selectively cache pages into a local IndexedDB database so that when offline, they could browse those cached files (and this appcache issue would be needed to ensure the application itself would still work in these cases).
Appcache doesn't only cache the designated files, it also implicitly caches the page that has the 'manifest' attribute. That page could be included in the NETWORK section of the manifest, so that it's always pulled from remote, but that would be tricky if the manifest is to be present on every wiki page. I am currently using an application cache in an extension that makes SemanticForms available for offline data entry. To do this the manifest file is only loaded on particular pages, and lists all reasourceloader URLs along with the cache keys. It also lists all of the pages that need to be made available offline, and their last-modified dates. Basically, it seems that the tricky part of appcache is making sure it's refreshed at the appropriate time.
