W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2011

[whatwg] Application Cache, Application Cache, Application Cache

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Sun, 17 Apr 2011 14:43:52 +0300
Message-ID: <E3A33460BFFD4CF8A6C756BF8DD90655@JukanPC>
Edward Gerhold wrote:

> I came to the conclusion, the cache is linked too tightly to the
> manifest.

The manifest appears to be the heart of the matter, so by questioning its 
tight connection to the application cache, you're questioning the 
application cache itself. This may well be a good question.

> The cache is good how it is as long as it isn?t developed
> for dynamic websites and caches.

Is it?

I'd like to see a simple summary of the benefits of an application cache, as 
compared with normal caching - not with some hypothetical situation without 
any caching. Even for a relatively stable application, the benefits don't 
appear to be that great, though I might miss something. If you expect an 
application to be updated rarely, you could set the HTTP headers to reflect 
this, encourageing browsers into regarding cached copies as fresh for a long 
time - or you might even let the normal guessing mechanisms (based on 
Last-Modified etc.) take care of this.

An application cache means that
1) an author can specify a set of resources to be loaded when a page is 
accessed
2) when online, the user's browser can check just the contents of the 
manifest to decide whether the cached files can be used, instead of checking 
the freshness of the individual files.

As a drawback, when _any_ change is made to any of the files, the manifest 
needs to be modified and all user agents will have to download the entire 
application (all files) when online next time.

I'm not very convinced of the benefits of this approach. Point (1) is 
somewhat fictitional: you might just as well let the browser download the 
files when the user uses the application for the first time. Admittedly, one 
session might not cause all the files to be downloaded, since it might not 
refer to all of them, especially if it is just a testing session. If this is 
serious, then I'd expect to find a solution that lets the author specify a 
list of files to be downloaded when an application is run, without affecting 
caching in any other way.

Point (2) might be relevant if the application consists of a large number of 
files, since otherwise the advantage is not that considerable. Basing the 
caching on the _contents_ of the manifest file sounds almost like a joke - 
why not let the browser just do a HEAD request and use Last-Modified to 
decide whether the manifest needs to be fetched?

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/ 
Received on Sunday, 17 April 2011 04:43:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:03 GMT