Re: Fixing appcache: a proposal to get us started

On 26 March 2013 07:02, Jonas Sicking <jonas@sicking.cc> wrote:

> {
>   "expiration": 300,
>   "cache": ["index.html", "index.js", "index.css"]
> }
>
> If the user navigates to index.html The following happens:
>
> If the user is online and we haven't checked for update for the
> appcache in the last 5 minutes (300 seconds) we simply ignore the
> cache and load index.html and any resources it links to from the
> network.
>

How is "online" defined here? What if we're online but the page 404s, what
if we're online but DNS to that domain fails etc etc.

Offline-first isn't intuitive, I agree. I did some hacking with FALLBACK to
get online-first behaviour in Lanyrd and quickly learned why it's a bad
idea, offline performance was dire as the device had to fail to connect
before it'd show me cached data. I'd rather stick with offline-first but
present it in a way that's expected.


> If the user is offline, or if we checked for update for the appcache
> within the last 5 minutes, we use the index.html from the appcache
> without hitting the network first. If index.html uses index.js or
> index.css, those will be immediately loaded from the cache.
>

Is the opposite true? If index.html is loaded from the network will
index.js ever come from the cache? (current appcache says no)


> Whenever we check for updates for an appcache with the above manifest
> we do an if-modified-since/if-none-match for the manifest. We then do
> an update check for any resource requested by the manifest. I.e. even
> if the manifest hasn't changed we still do an update check for each
> resource linked to by the manifest. If any resources were added since
> the previous manifest those are obviously simply downloaded. If any
> resources were removed from the manifest those are discarded. As an
> optimization the UA can start doing update checks on the same set of
> URLs that the previous version of the manifest contained.
>

Don't get the last line, does "the same set of URLs that the previous
version of the manifest contained" mean "URLs that are in the current
version, and also the previous version"? Is this suggesting that obeying
HTTP cache headers is an optional optimisation?


> {
>   "version": "5.1",
>   "expiration": 300,
>   "cache": ["index.html", "index.js", "index.css"]
> }
>
> For this manifest, when we want check for update for the cache we
> first do a if-none-match/if-modified-since check for the cache object
> itself. If we get back a new resource, *and* that resource contains a
> new value for the version property, then we do update checks for all
> resources as well as download any new ones.
>

+1, having an explicit version property is a much better idea than the
string matching in the current manifest.


> In order to further cut down on the number of network requests, we'd
> also enable providing last-modified dates or etags directly in the
> manifest:
>
> {
>   "expiration": 300,
>   "cache": [{ url: "index.html", "etag": "84ba9f"},
>             { url: "index.js", "last-modified": "Wed, 1 May 2013
> 04:58:08 GMT" },
>             "index.css"]
> }
>

Adding these into the manifest would require some kind of automation, if
there's a level of automation couldn't it just change the url to
index.84ba9f.js and have rewriting or static generation take care of the
rest?

{
>   "expiration": 300,
>   "cache": ["index.html", "index.js", "index.css"],
>   "cookie-vary": "uid"
> }
>
> This would mean that even if the user is offline and navigates to
> index.html, if the value of the "uid" cookie is different from when
> the appcache was last updated, the appcache would not be returned. A
> UA could even use the value of the "uid" cookie as an additional key
> in its appcache registry and thus support keeping appcaches for
> different users on the same device.
>

If I have an expiration of a day, and log out as one user log in with
another, then get on a plane, none of my content would be available to me?


> The actual AppCache object has the following API:
>

I'm worried the API here loses the simplicity that this proposal is
supposed to have over the scripted solution, where you have to learn a
manifest format and how it interacts with items added via its scripting
API, whereas the navigation controller only has a scripting API.

Is there anything here that couldn't be done with the NavigationController
& a library? I'm not suggesting that's reason for it not to exist, just
wondering if it's offering anything unique.

Jake.