[whatwg] Appcache feedback

Wed Feb 2 13:27:54 PST 2011

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.