- From: Jake Archibald <jaffathecake@gmail.com>
- Date: Tue, 11 Sep 2012 15:26:45 +0100
- To: Tobie Langel <tobie@fb.com>
- Cc: "public-fixing-appcache@w3.org" <public-fixing-appcache@w3.org>
On 11 September 2012 14:30, Tobie Langel <tobie@fb.com> wrote: > Is this missing features for the use cases we are interested in? Currently appcache provides a transactional way to cache files, if any file listed in the manifest fails to download, the whole caching process fails. Unfortunately it's all or nothing, whereas Lanyrd/FT want to divide these up into groups. Eg, one group for the framework, then additional groups per issue (FT) or event (Lanyrd), I can imagine games developers wanting to do the same with levels. If the framework caches, but one of the events fails (eg loss of connection), we'd be happy with the framework & successful events caching. We'd also want to be able to add/expire additional events later. The zip file method provides the packaging, but isn't as efficient the current appcache system when it comes to updates. If I want to update a js file I can change the manifest to point at the new js file. if I've been smart with caching headers, only the js file will be downloaded. The zip system means downloading the whole package again for any change, depending on the situation this could be a large download for a small change. Jake.
Received on Tuesday, 11 September 2012 14:27:14 UTC