- From: Michael Nordman <michaeln@google.com>
- Date: Mon, 11 Apr 2011 09:45:44 -0700
- To: louis-rémi BABE <lrbabe@gmail.com>
- Cc: public-webapps@w3.org
- Message-ID: <BANLkTimAH9k2mUkR-KUfCxxd87vGxHnb7Q@mail.gmail.com>
2011/4/7 Michael Nordman <michaeln@google.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. > > Also, I'm looking for a syntax that adds this new capability in a non-breaking way. I want to avoid changing the semantics of the any existing API since it's already shipped. > >> >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 Monday, 11 April 2011 16:46:13 UTC