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

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

--- Comment #24 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-12-13 23:41:14 UTC ---
That's essentially black-box indistinguishable from the "proposed appcache
mechanism" I modeled in comment 20, assuming an incremental approach (i.e.
start using the resources as soon as possible, with the caching going on in
parallel).

The performance characteristics of such a model seem rather poor (barely
distinguishable from straight HTTP caching in the common case). I don't really
see the benefit.

At the end of the day, assuming you can properly set up your HTTP caching
(which is easy — set long expiry times and change the resource URLs when they
are updated, pretty standard practice), I really don't see how adding a
manifest makes much of a difference, other than making the file available
offline.


Anyway, as pointless as I think this feature is, since people want to implement
and people want to use it, my opinion doesn't really matter.

Here's what I propose:
 - add a new section to manifests which works like the CACHE section, but also
flags the resources with a new flag.
 - when you fetch a file during navigation and it's in an appcache but has this
new flag and isn't marked foreign, fetch it from the network and immediately
kick off a cache update.
 - if the file comes back 200, then act as if you were not associated with an
appcache (same as the first time you fetch a file that later is found to have a
manifest), except use the existing appcache as an HTTP cache. Once the appcache
update is complete, treat the appcache as if it was guaranteed to hold the
latest copies of everything it has, so you never have to hit the network for
cached resources. If the file is found to not have a manifest="", then mark the
entry as foreign.
 - if the file comes back with any other code, load it from the appcache as
normal.

Is that satisfactory?

-- 
Configure bugmail: https://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 Tuesday, 13 December 2011 23:41:16 UTC