RE: Where we stand...

On advice from the chairs, see http://lists.w3.org/Archives/Public/public-html/2012Sep/0060.html.

From: Chris Wilson [mailto:cwilso@google.com]
Sent: Thursday, September 6, 2012 3:05 PM
To: Patrick Gillespie; Adrian Bateman
Cc: public-fixing-appcache@w3.org
Subject: Re: Where we stand...

1) I also had someone ask me about a use case that I don't see listed, but it's fairly high level; is there a reason I am naively not understanding why we don't have any provision for background updating?

2) I'm ambivalent, as I said at the MTV meeting, but are we going to follow up on this issue here or have a sub-list in the HTML WG?
On Thu, Sep 6, 2012 at 10:18 AM, Patrick Gillespie <patorjk@gmail.com<mailto:patorjk@gmail.com>> 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.

best,

- Pat