- From: Michael Nordman <michaeln@google.com>
- Date: Wed, 2 Feb 2011 13:27:54 -0800
On Mon, Jan 31, 2011 at 4:20 PM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 11 Nov 2010, Michael Nordman wrote: >> >> In section "6.6.6 Changes to the networking model" which applies to sub >> resource loads, step 3 prevents returning fallback resources for >> requested urls that fall into a network namespace. >> >> In section "6.5.1 Navigating across documents" which applies to main >> resource loads, step 17 does not explicitly exclude returning fallbacks >> for such urls. >> >> I doubt this difference is intentional, looks like step 17 needs some >> <additional words>... >> >> "If the resource was not fetched from an application cache, and was to >> be fetched using HTTP GET or equivalent, and its URL matches the >> fallback namespace <but not the network namespace> of one or more >> relevant application caches..." > > I assume you mean the online whitelist, not the "network namespace". > > I've adjusted the spec as you suggest. Thank you. > On Mon, 20 Dec 2010, Michael Nordman wrote: >> >> ---------- Forwarded message ---------- > | From: UVL <andrea.doimo at gmail.com> > | Date: Sun, Dec 19, 2010 at 1:35 PM > | Subject: [chromium-html5] Application Cache for on-line sites > | To: Chromium HTML5 <chromium-html5 at chromium.org> > | > | I tried to use the HTML5 Application Cache to improve the performances > | of on-line sites (all the tutorials on the web write only about usage > | with off-line apps) > | > | I created the manifest listing all the js, css and images, and the > | performances were really exciting, until I found that even the page HTML > | was cached, despite it was not listed in the manifest. The pages of the > | site are in PHP, so I don't want them to be cached. > | > | From > | http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html > | : "Authors are encouraged to include the main page in the manifest also, > | but in practice the page that referenced the manifest is automatically > | cached even if it isn't explicitly mentioned." > | > | Is there a way to have this automating caching disabled? > | > | Note: I know that caching can be controlled via HTTP headers, but I just > | wanted to try this way as it looks quite reliable, clean and powerful. >> >> This type of request [...] to utilize the application cache for >> subresource loads into documents that are not stored in the cache has >> come up several times now. The current feature set is very focused on >> the "offline" use case. Is it worth making additions such that a >> document that loads from a server can utilize the resources in an >> appcache? >> >> Today we have <html manifest="manifestFile">, which adds the document >> containing this tag to the appcache and associates that doc with that >> appcache such that subresource loads hit the appcache. >> >> Not a complete proposal, but... >> >> What if we had something along the lines of <html >> useManifest=''manifestFile">, which would do the association of the doc >> with the appcache (so subresources loads hit the cache) but not add the >> document to the cache? > > Why can't the pages just switch to a more AJAX-like model rather than > having the main page still load over the network? The main page loading > over the network is a big part of the page being slow. The premise of the feature request is that the "main" pages aren't cached at all. | I tried to use the HTML5 Application Cache to improve the performances | of on-line sites (all the tutorials on the web write only about usage | with off-line apps) As for "why can't the pages just switch", I can't speak for andrea, but i can guess that a redesign of that nature was out of scope and/or would conflict with other requirements around how the url address space of the app is defined.
Received on Wednesday, 2 February 2011 13:27:54 UTC