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 20:09:52 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1ROxQ8-0006U5-Ne@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14702

--- Comment #8 from michaeln@google.com 2011-11-11 20:09:51 UTC ---
Solving this problem would go a long way to "fixing" the appcache and make
broader adoption possible. Imho, this is the biggest piece of low hanging fruit
to take care of and the most often requested change.

> So this is basically requesting...

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.

The automagic pinning of 'master' is often not desired. And once added to the
cache, there is no way to remove one from the cache. This automagic behavior
may be causing more problems then its solving imo.

There's more than one way to express the desire to "use but not add" in the API
(pick your bike shed color).

a. A new html element attribute

   <html useManifest='xxx'>

b. A new OPTIONS section in the manifest file to turn off automagic adding of
master entries. (this is essentially what ms has done with different string
constants).

   OPTIONS:
   cache-master-entries = false


Once you get past the syntax, there are some questions about how exactly the
subresources can be utilized during page load, we don't want to load stale
content.  The second link below starts to address those questions.

There were some posts to the whatwg list on exactly this topic from last feb.
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030410.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030590.html

-- 
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 20:09:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 11 November 2011 20:09:56 GMT