W3C home > Mailing lists > Public > public-html@w3.org > September 2012

RE: Evolving AppCache discussions

From: Sunyang (Eric) <eric.sun@huawei.com>
Date: Fri, 21 Sep 2012 06:14:05 +0000
To: Adrian Bateman <adrianba@microsoft.com>, "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>
Message-ID: <9254B5E6361B1648AFC00BA447E6E8C32AECCE86@szxeml545-mbx.china.huawei.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 September 2012 06:16:38 GMT