- From: Michael Nordman <michaeln@google.com>
- Date: Thu, 7 Apr 2011 15:47:46 -0700
- To: louis-rémi BABE <lrbabe@gmail.com>
- Cc: public-webapps@w3.org
- Message-ID: <BANLkTikKnfL4iBBUcPEkpurKKOuFNFZ03w@mail.gmail.com>
2011/4/7 louis-rémi BABE <lrbabe@gmail.com> > Thank you all for your valuable answers. > > There seems to be a pretty solid agreement on "ability to exclude the > master page form the cache". > Michael, you are suggesting using a different way of referring to the > manifest: <http useManifest='x'> > Why not just let it be listed in the NETWORK section of the manifest? > It would make the means of including or excluding resources from the > cache more consistent. > I think the <html> tag syntax is a better API for the reasons mentioned in the whatwg list, i'll reiterate them here... > A few ideas on syntax... > a. <html useManifest='x'> > b. If the main resource has a "no-store" header, don't add it to the > cache, but do associate the document with the cache. > c. A new manifest section to define a prefix matched namespace for these pages. Option (c) isn't precisely targeted at individual resources, authors would have to arrange their URL namespace more carefully to achieve the desired results. Option (a) and (b) can be applied specifically to individual pages offering greater control over. And option (a) is the more explicit the two. Authors need only edit the page to get the desired result instead of having to arrange for the appropiate http headers. Readers of the code (and view sourcers of the pages) can more easily determine how this page should utilize the appcache just by looking at the source of the page. My pick would be option (a), <html useManifest='x'> The summary is that the <html useManifest='x'> is cleaner and clearer imo. The NETWORK section doesn't actually exclude resources from being added to the cache. For example you can explicitly list a url in the CACHE section, and again in the NETWORK section... guess what... the resource is added to the cache and will be utilized. > > >Allow cross-origin HTTPS resources to be included in manifest files. > >This much is actually done already in chromium impl as described on the > whatwg list. > Is it already available in a stable version of Chrome? > Chrome 11 should hit the stable channel in ~18 days. It's in the beta channel now. > I would also like to see this one fully implemented in Firefox asap. > I'll get in touch with our developers. > Fantastic! I'll open a bug in webkit to do the same since. > Micheal, have you got use-cases for the 4th and 5th feature request of > this thread [1]? > This feature is more architecture driven than use-case driven. Without such a feature, while in many cases there may be a way to produce a solution that functions 'offline', the trouble is that it's a completely different solution than in the 'online' case. I'll follow up with you about these features in particular. > And could you please keep me updated with your implementation efforts > in Chromium? > I would be very happy to and likewise would be appreciated. > > Regards, > > Louis-Rémi > > [1] > http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/1121.html > >
Received on Thursday, 7 April 2011 22:48:10 UTC