W3C home > Mailing lists > Public > public-fixing-appcache@w3.org > November 2012

Re: Version identifier

From: Jake Archibald <jaffathecake@gmail.com>
Date: Sat, 3 Nov 2012 09:41:10 +0000
Message-ID: <CAJ5xic-wj5DPqBWYAYLN0ZWyohy_3kSj5M=Y2itBvZ81FVJ=ww@mail.gmail.com>
To: Michael Nordman <michaeln@google.com>
Cc: Andrew Betts <andrew.betts@ft.com>, "public-fixing-appcache@w3.org" <public-fixing-appcache@w3.org>, Chris Wilson <cwilso@google.com>
On 2 November 2012 20:41, Michael Nordman <michaeln@google.com> wrote:
> In some internal discussions about the
> 'prefer-online' setting, we were seeking a means of being able to load a
> page over the network that could immediately load resources out of an
> existing application cache.

What does this achieve that can't be done with the HTTP cache?
(must-revalidate on page, far-future cache on resources)

> The way things currently are, prior to just
> hitting the appcache, the manifest file of that existing cache has to be
> validated which generally requires a server roundtrip. We were seeking to
> eliminate that round trip and thought that more explicit versioning could
> help...
>    <html manifest="file" manifestVersion="2">

This only works if your page is "prefer-online", otherwise the html
page containing the new version number won't be seen as the browser
will fetch the previous version of the page from the appcache. The
browser will only see the updated version number when the browser
updates the appcache (due to a change in the manifest file), meaning
the thing signalling an update is available is only seen when an
update is made.

If you're only targeting the "prefer-offline" case, you could
eliminate the manifest http request by far-future caching it &
changing it's url when there's a change (essentially moving
manifestVersion into the manifest url), as you'd do with other page
assets (css/js/img).

The problem with manifestVesion and far-future caching the manifest is
it's too easy to end up with a strongly cached page that can only be
updated by a similarly strongly cached manifest, and vice versa. This
locks the user into a particular version of the site.
Received on Saturday, 3 November 2012 09:41:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:41:26 UTC