W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2011

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

From: <bugzilla@jessica.w3.org>
Date: Fri, 11 Nov 2011 22:47:36 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1ROzsm-0004Fw-Dq@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14702

--- Comment #11 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-11-11 22:47:35 UTC ---
(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.


> AppCache contains this functionality already with FALLBACK. The problem is that
> the master entry cannot currently participate in the FALLBACK contract. This
> means a news site that I want to enable while disconnected is always shown out
> of date even when connected.

This is incorrect. URLs that match FALLBACK entries, once cached, are served
from the cache, not from the network as is being requested here. The only
reason you can't use FALLBACK with a master entry is that the master entry is
already cached.


(In reply to comment #8)
> 
> 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.)

-- 
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 Friday, 11 November 2011 22:47:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 11 November 2011 22:47:47 GMT