RE: Evolving AppCache discussions

Hi all

I support using a new mail list for appcache, using separate mail list make it more easy for us to categorize so many emails every day.

Yang
Huawei

> -----Original Message-----
> From: Adrian Bateman [mailto:adrianba@microsoft.com]
> Sent: Saturday, September 08, 2012 12:45 AM
> To: HTML WG (public-html@w3.org)
> Cc: Paul Cotton; Sam Ruby (rubys@intertwingly.net); Maciej Stachowiak
> (mjs@apple.com)
> Subject: Evolving AppCache discussions
> 
> 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.h
> tml
> * 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, 21 September 2012 06:16:38 UTC