- From: Adrian Bateman <adrianba@microsoft.com>
- Date: Fri, 7 Sep 2012 16:45:25 +0000
- To: "HTML WG (public-html@w3.org)" <public-html@w3.org>
- CC: Paul Cotton <Paul.Cotton@microsoft.com>, "Sam Ruby (rubys@intertwingly.net)" <rubys@intertwingly.net>, "Maciej Stachowiak (mjs@apple.com)" <mjs@apple.com>
In the last few weeks there have been a couple of meetings with people discussing the status of AppCache (notes at [1] and [2]). In my mind, this is a follow-on discussion from the W3C Workshop on The Future of Offline Web Applications [3] held after TPAC last year. The report [4] from that workshop included a recommendation to work on "Fixing" Application Cache. My proposal is that this discussion should be continued in the HTML WG where the current AppCache API is specified. Since there are some people who wish to participate in this work but only engage in this one activity, the consensus of our small group in Mountain View was to propose a new mailing list (public-html-appcache) to host the discussion (in a similar way to the public-html-media list). We also agreed that we should start with the current AppCache feature and evolve to solve the issues we have identified. I would like to propose such a mailing list and, in my view, this work should be part of HTML.next to ensure that it does not block progress on HTML5. Cheers, Adrian. For reference, here are our high-level ideas for things that we would address in this work: * Get rid of master entries concept * When navigating, look for an appcache which contains that URL, rather than look for an appcache which has that URL as master entry. * Would require enumerating which URLs the appcache should "capture". If there are multiple appcaches that capture the same URL, use the one which contains the most recent entry (was updated most recently?). * JS-API for adding/removing/enumerating entries * JS-API for creating/deleting/enumerating appcaches + https://bugs.webkit.org/show_bug.cgi?id=67135 * The chrome INTERCEPT section + http://code.google.com/p/chromium/issues/detail?id=101565 * Knowing if you're being served from appcache or not. And which version of the appcache. We'd have to add an official version indicator in the manifest which is exposed through JS-API. * Sticking the etag in the appcache manifest allows not doing if-modified-since requests for all non-updated resources. http://blog.sethladd.com/2010/10/proposal-to-enhance-html5-app-cache.html * Having an expiration time in the appcache manifest makes sure that user isn't running an old exploitable version. * The syntax for fallback, which mixes "follow this network-stat rule" and "cache this resource" in one rule is confusing. * Ability to write a HTTP server in JS which handle URI spaces. + http://www.w3.org/TR/DataCache/ + http://code.google.com/p/chromium/issues/detail?id=101800 * Network:* should be default mode [1] https://etherpad.mozilla.org/appcache-london [2] https://etherpad.mozilla.org/appcache [3] http://www.w3.org/2011/web-apps-ws/ [4] http://www.w3.org/2011/web-apps-ws/Report
Received on Friday, 7 September 2012 16:46:46 UTC