- From: Andrew Betts <andrew.betts@ft.com>
- Date: Fri, 7 Sep 2012 05:44:49 +0100
- To: Patrick Gillespie <patorjk@gmail.com>
- Cc: public-fixing-appcache@w3.org
On 6 Sep 2012, at 18:18, Patrick Gillespie wrote: > I didn't see this listed in the use cases, so I figured I'd throw it out there. It'd be nice if a web app could behave as normal and use the HTTP cache, but if a user was unable to connect to an app's server, the browser would instead load a Fallback version of the app. This would be of a benefit for legacy applications that aren't architected in a way to take advantage of appcache, but still want to leverage the ability to work offline / give a better user experience if the app is offline. For example, say you have an app on an internal network that users use every day. If its server or network connection goes down, a fallback version of the app could be loaded - and the developer could make this anything from a simple information page that attempted to periodically reconnect, to a lightweight version of the app. You can do this now if your app itself is cached, but you can't have just an offline / fallback version. I don't see why you can't - doesn't the app cache FALLBACK syntax provide for this? You just have a single rule in the FALLBACK section, resolving all uncached entries to a single cached resource, eg: FALLBACK: / /offline.html That could be your info page that periodically tries to reconnect. App cache actually seems pretty well suited to this, apart from that it will probably cache all your site's pages as implicit master entries because you'd need to reference the manifest from every entry point into the site. Andrew -- ------------------------------ This email was sent by a company owned by Pearson plc, registered office at 80 Strand, London WC2R 0RL. Registered in England and Wales with company number 53723.
Received on Friday, 7 September 2012 13:16:44 UTC