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

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

--- Comment #13 from michaeln@google.com 2011-11-12 00:54:13 UTC ---
(In reply to comment #11)
> (In reply to comment #7)
> > This is better than the HTTP cache for all the reasons why AppCache needs to
> > exist at all: to provide a predictable life time for the caching of content.
> 
> Appcache does not provide a predictable lifetime for cached content. Nothing
> stops a UA from arbitrarily evicting an appcache.

In practice, an appcached resource will generally outlive an http cached
resource. We're looking for ways to take advantage of that.

> > The way i understand this request is to allow pages retrieved over the network
> > to utilize the resources in an application cache for subresource loads, without
> > itself being added to that application cache. The point is to speed up
> > subresource loads.
> 
> This is *exactly* what an HTTP cache does. You don't need appcache for this
> specific feature. (This is not what was described earlier in this bug,
> however.)

The essence of this request is to define some semantics whereby 'online' sites
can effectively make use of appcached resources. Consider a site that has
populated an appcache with many megabytes of resources. To rely on the HTTP
cache would likely mean to redownload all of them when first visiting the site
after having been away for a while (costly), then things work great. (And then
if they wanted an appcache to be updated as an artifact of visiting the
'online' page, they'd have to do that separately with a iframe (hassle)). We're
looking for a way for things to work great from the git go without having to
repopulate the http cache and without having to hack around with iframes.

The combination of *dont-cache-masters* + *fallbacks* is one way to provide
semantics along those lines. If a request for an online-only-master succeeds,
it should be able to dip into the pile of appcached resources w/o incurring
roundtrips (in many cases). If a request for an online-only-master fails, a
fallback thats explicitly listed in the manifest can be used. 

I'm less worried about the guy that doesn't know how to use JavaScript than the
professional developer than can't do much with the feature set as it stands
because its too narrowly focused on unrealistic use cases.

-- 
Configure bugmail: http://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, 12 November 2011 00:54:19 UTC