[Bug 14702] appcache: always up-to-date applications

https://www.w3.org/Bugs/Public/show_bug.cgi?id=14702

Jake Archibald <jaffathecake@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jaffathecake@gmail.com

--- Comment #33 from Jake Archibald <jaffathecake@gmail.com> 2012-03-03 15:12:05 UTC ---
We had this use case on http://m.lanyrd.com/. We wanted people to be able to
access their tracked/attended events offline, but browsing the site would
provide the latest (not app cached) data. We wanted the site to be spiderable
by search engines, and didn't want to rely on JS.

Working without JS meant we could extend our support to older devices (and
opera mini) by preventing those devices parsing most of the JS based on a few
simple bits of feature detection. The performance benefit from this on the old
blackberry browser was measurable in seconds.

We worked around the problem by having every page include a hidden iframe
pointing to our fallback page, which had a manifest which included all our
css/js/assets. This means any page visit informs the browser of the manifest,
without the visited page being a master entry.

When a connection fails to a page the app cache takes over. The fallback page
gets its data from localstorage & mustache templates (which are shared with the
server) from a json object included in the page.

The downsides to this approach are having to wait for a connection to fail
before showing the cached version, which is fine in "no signal" cases but can
cause a delay in "some but not enough signal" cases. We can live with this.

Also, the conditions in which the connection is seen to fail are pretty broad,
eg site throws a 500, dns failure, 404, off-domain redirect. This is good, but
once we're in the cached version we have no idea which of those happened,
making our error messages a bit vague. Eg, see http://m.lanyrd.com/404 (when
you have a populated app cache)

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 3 March 2012 15:12:14 UTC