Re: [whatwg] Application Cache for on-line sites
On Fri, Feb 11, 2011 at 1:14 PM, Michael Nordman wrote: > Once you get past the "should this be a feature" question, there are > some questions to answer. I'll take a stab at answering these questions. > 1) How does an author indicate which pages should be added to the > cache and which should not? > > A few ideas... > a. > 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), > 2) What sequence of events does a page that just uses the cache w/o > being added to it observe? The same sequence of events as a master entry that does get added to the cache. > 3) At what point do subresources in an existing appcache start getting > utlized by such pages? What if the appcache is stale? Do subresource > loads cause revalidation? Swap the cache into use upon successful update completion, so again just like for master entry pages that do get added to the cache. But this observation is the crux of it. There's a window of time between page loading and update completion. During that interim resources resident in the appcache can be used to effectively augment the browser's regular HTTP cache. For example, when the page requests a subresource and the resource in the appcache is fresh enough per http caching rules, it may be returned immediately w/o any validation. WDYT?
Re: [whatwg] Application Cache for on-line sites
I have a use case where it is preferable that the main page is not cached: Suppose you have a main page that changes based on it's ID: http://example.com/page.php?id=10 The appCache will store each main page with different id in separate cache, which is undesirable! And we DON'T want to cache the main pages, since the content differs significantly (think of it as a forum website). Of course, you can make the page.php as an "application" entirely, then the id + its content are loaded via AJAX, but that violates the nature of URL linking! Other websites cannot easily link to the "application" with page id = 10 (since you remove the "?id=10" from the URL). Of course you can use "SHE BANG" into the URL (to specify the id) to bookmark (or to link to) AJAX pages, but that means browsers without Javascript enabled will break! (it doesn't degrade gracefully). That is why, we have to have a mechanisms to exclude the main page to be cached. The main goal here is NOT to make the page offline, but to cache the resources that the page uses (i.e, .js, .css, images, etc...) that are very likely to be IMMUTABLE (particularly the jQuery.js and jQueryUI css+images that almost every sites uses!). It should degrade gracefully for older browsers if they don't understand the manifest files. Felix Halim On Sat, Feb 12, 2011 at 7:03 AM, Jeremy Orlow wrote: > bcc chromium-html5 > > In addition to what Michael has cited, I've had many developers (at various > Google events) ask why we don't have some API like this as well. I think > it's clear there's demand. > > On Fri, Feb 11, 2011 at 1:14 PM, Michael Nordman wrote: > >> Waking this feature request up again as it's been requested multiple >> times, I think the ability to utilize an appcache w/o having to have >> the page added to it is the #1 appcache feature request that I've >> heard. >> >> * The Gmail mobile team has mentioned this. >> >> * Here's a thread on a chromium.org mailing list where this feature is >> requested: "How to instruct the main page to be not cached?" >> >> https://groups.google.com/a/chromium.org/group/chromium-html5/browse_thread/thread/a254e2090510db39/916f3a8da40e34f8 >> >> * More recently this has been requested in the context of an >> application that uses pushState to alter the url of the main page. >> >> To keep this discussion distinct from others, I'm pulling in the few >> comments that have been made on another thread. >> >> hixie said... >> > Why can't the pages just switch to a more AJAX-like model rather than >> > having the main page still load over the network? The main page loading >> > over the network is a big part of the page being slow. >> >> and i replied... >> > The premise of the feature request is that the "main" pages aren't >> > cached at all. >> > >> > | I tried to use the HTML5 Application Cache to improve the performances >> > | of on-line sites (all the tutorials on the web write only about usage >> > | with off-line apps) >> > >> > As for "why can't the pages just switch", I can't speak for andrea, >> > but i can guess that a redesign of that nature was out of scope and/or >> > would conflict with other requirements around how the url address >> > space of the app is defined. >> >> Once you get past the "should this be a feature" question, there are >> some questions to answer. >> >> 1) How does an author indicate which pages should be added to the >> cache and which should not? >> >> A few ideas... >> a. >> 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. >> b. A new manifest section to define a prefix matched namespace for these >> pages. >> >> 2) What sequence of events does a page that just uses the cache w/o >> being added to it observe? >> >> 3) At what point do subresources in an existing appcache start getting >> utlized by such pages? What if the appcache is stale? Do subresource >> loads cause revalidation? >> >> On Mon, Dec 20, 2010 at 12:56 PM, Michael Nordman >> wrote: >> > This type of request (see forwarded message below) to utilize the >> > application cache for subresource loads into documents that are not >> stored >> > in the cache has come up several times now. The current feature set is >> very >> > focused on the "offline" use case. Is it worth making additions such that >> a >> > document that loads from a server can utilize the resources in an >> appcache? >> > Today we have , which adds the document >> > containing this tag to the appcache and associates that doc with that >> > appcache such that subresource loads hit the appcache. >> > Not a complete proposal, but... >> > What if we had something along the lines of > > useManifest=''manifestFile">, which would do the association of the doc >> with >> > the appcache (so subresources loads hit the cache) but not add the >> document >> > to the cache? >> > >> > -- Forwarded message -- >> > From: UVL >> > Date: Sun, Dec 19, 2010 at 1:35 PM >> > Subje
Re: [whatwg] Application Cache for on-line sites
bcc chromium-html5 In addition to what Michael has cited, I've had many developers (at various Google events) ask why we don't have some API like this as well. I think it's clear there's demand. On Fri, Feb 11, 2011 at 1:14 PM, Michael Nordman wrote: > Waking this feature request up again as it's been requested multiple > times, I think the ability to utilize an appcache w/o having to have > the page added to it is the #1 appcache feature request that I've > heard. > > * The Gmail mobile team has mentioned this. > > * Here's a thread on a chromium.org mailing list where this feature is > requested: "How to instruct the main page to be not cached?" > > https://groups.google.com/a/chromium.org/group/chromium-html5/browse_thread/thread/a254e2090510db39/916f3a8da40e34f8 > > * More recently this has been requested in the context of an > application that uses pushState to alter the url of the main page. > > To keep this discussion distinct from others, I'm pulling in the few > comments that have been made on another thread. > > hixie said... > > Why can't the pages just switch to a more AJAX-like model rather than > > having the main page still load over the network? The main page loading > > over the network is a big part of the page being slow. > > and i replied... > > The premise of the feature request is that the "main" pages aren't > > cached at all. > > > > | I tried to use the HTML5 Application Cache to improve the performances > > | of on-line sites (all the tutorials on the web write only about usage > > | with off-line apps) > > > > As for "why can't the pages just switch", I can't speak for andrea, > > but i can guess that a redesign of that nature was out of scope and/or > > would conflict with other requirements around how the url address > > space of the app is defined. > > Once you get past the "should this be a feature" question, there are > some questions to answer. > > 1) How does an author indicate which pages should be added to the > cache and which should not? > > A few ideas... > a. > 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. > b. A new manifest section to define a prefix matched namespace for these > pages. > > 2) What sequence of events does a page that just uses the cache w/o > being added to it observe? > > 3) At what point do subresources in an existing appcache start getting > utlized by such pages? What if the appcache is stale? Do subresource > loads cause revalidation? > > On Mon, Dec 20, 2010 at 12:56 PM, Michael Nordman > wrote: > > This type of request (see forwarded message below) to utilize the > > application cache for subresource loads into documents that are not > stored > > in the cache has come up several times now. The current feature set is > very > > focused on the "offline" use case. Is it worth making additions such that > a > > document that loads from a server can utilize the resources in an > appcache? > > Today we have , which adds the document > > containing this tag to the appcache and associates that doc with that > > appcache such that subresource loads hit the appcache. > > Not a complete proposal, but... > > What if we had something along the lines of > useManifest=''manifestFile">, which would do the association of the doc > with > > the appcache (so subresources loads hit the cache) but not add the > document > > to the cache? > > > > -- Forwarded message -- > > From: UVL > > Date: Sun, Dec 19, 2010 at 1:35 PM > > Subject: [chromium-html5] Application Cache for on-line sites > > To: Chromium HTML5 > > > > > > I tried to use the HTML5 Application Cache to improve the performances > > of on-line sites (all the tutorials on the web write only about usage > > with off-line apps) > > > > I created the manifest listing all the js, css and images, and the > > performances were really exciting, until I found that even the page > > HTML was cached, despite it was not listed in the manifest. The pages > > of the site are in PHP, so I don't want them to be cached. > > > > From > > http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html > > : > > "Authors are encouraged to include the main page in the manifest also, > > but in practice the page that referenced the manifest is automatically > > cached even if it isn't explicitly mentioned." > > > > Is there a way to have this automating caching disabled? > > > > Note: I know that caching can be controlled via HTTP headers, but I > > just wanted to try this way as it looks quite reliable, clean and > > powerful. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Chromium HTML5" group. > > To post to this group, send email to chromium-ht...@chromium.org. > > To unsubscribe from this group, send email to > > chromium-html5+unsubscr...@chromium.org. > > For more options, visit this group at > > http://groups.google.com/a/chromium.org/group/chromium-html5/?hl
Re: [whatwg] Application Cache for on-line sites
Waking this feature request up again as it's been requested multiple times, I think the ability to utilize an appcache w/o having to have the page added to it is the #1 appcache feature request that I've heard. * The Gmail mobile team has mentioned this. * Here's a thread on a chromium.org mailing list where this feature is requested: "How to instruct the main page to be not cached?" https://groups.google.com/a/chromium.org/group/chromium-html5/browse_thread/thread/a254e2090510db39/916f3a8da40e34f8 * More recently this has been requested in the context of an application that uses pushState to alter the url of the main page. To keep this discussion distinct from others, I'm pulling in the few comments that have been made on another thread. hixie said... > Why can't the pages just switch to a more AJAX-like model rather than > having the main page still load over the network? The main page loading > over the network is a big part of the page being slow. and i replied... > The premise of the feature request is that the "main" pages aren't > cached at all. > > | I tried to use the HTML5 Application Cache to improve the performances > | of on-line sites (all the tutorials on the web write only about usage > | with off-line apps) > > As for "why can't the pages just switch", I can't speak for andrea, > but i can guess that a redesign of that nature was out of scope and/or > would conflict with other requirements around how the url address > space of the app is defined. Once you get past the "should this be a feature" question, there are some questions to answer. 1) How does an author indicate which pages should be added to the cache and which should not? A few ideas... a. 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. b. A new manifest section to define a prefix matched namespace for these pages. 2) What sequence of events does a page that just uses the cache w/o being added to it observe? 3) At what point do subresources in an existing appcache start getting utlized by such pages? What if the appcache is stale? Do subresource loads cause revalidation? On Mon, Dec 20, 2010 at 12:56 PM, Michael Nordman wrote: > This type of request (see forwarded message below) to utilize the > application cache for subresource loads into documents that are not stored > in the cache has come up several times now. The current feature set is very > focused on the "offline" use case. Is it worth making additions such that a > document that loads from a server can utilize the resources in an appcache? > Today we have , which adds the document > containing this tag to the appcache and associates that doc with that > appcache such that subresource loads hit the appcache. > Not a complete proposal, but... > What if we had something along the lines of useManifest=''manifestFile">, which would do the association of the doc with > the appcache (so subresources loads hit the cache) but not add the document > to the cache? > > -- Forwarded message -- > From: UVL > Date: Sun, Dec 19, 2010 at 1:35 PM > Subject: [chromium-html5] Application Cache for on-line sites > To: Chromium HTML5 > > > I tried to use the HTML5 Application Cache to improve the performances > of on-line sites (all the tutorials on the web write only about usage > with off-line apps) > > I created the manifest listing all the js, css and images, and the > performances were really exciting, until I found that even the page > HTML was cached, despite it was not listed in the manifest. The pages > of the site are in PHP, so I don't want them to be cached. > > From > http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html > : > "Authors are encouraged to include the main page in the manifest also, > but in practice the page that referenced the manifest is automatically > cached even if it isn't explicitly mentioned." > > Is there a way to have this automating caching disabled? > > Note: I know that caching can be controlled via HTTP headers, but I > just wanted to try this way as it looks quite reliable, clean and > powerful. > > -- > You received this message because you are subscribed to the Google Groups > "Chromium HTML5" group. > To post to this group, send email to chromium-ht...@chromium.org. > To unsubscribe from this group, send email to > chromium-html5+unsubscr...@chromium.org. > For more options, visit this group at > http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en. > > >
[whatwg] Application Cache for on-line sites
This type of request (see forwarded message below) to utilize the application cache for subresource loads into documents that are not stored in the cache has come up several times now. The current feature set is very focused on the "offline" use case. Is it worth making additions such that a document that loads from a server can utilize the resources in an appcache? Today we have , which adds the document containing this tag to the appcache and associates that doc with that appcache such that subresource loads hit the appcache. Not a complete proposal, but... What if we had something along the lines of , which would do the association of the doc with the appcache (so subresources loads hit the cache) but not add the document to the cache? -- Forwarded message -- From: UVL Date: Sun, Dec 19, 2010 at 1:35 PM Subject: [chromium-html5] Application Cache for on-line sites To: Chromium HTML5 I tried to use the HTML5 Application Cache to improve the performances of on-line sites (all the tutorials on the web write only about usage with off-line apps) I created the manifest listing all the js, css and images, and the performances were really exciting, until I found that even the page HTML was cached, despite it was not listed in the manifest. The pages of the site are in PHP, so I don't want them to be cached. From http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html : "Authors are encouraged to include the main page in the manifest also, but in practice the page that referenced the manifest is automatically cached even if it isn't explicitly mentioned." Is there a way to have this automating caching disabled? Note: I know that caching can be controlled via HTTP headers, but I just wanted to try this way as it looks quite reliable, clean and powerful. -- You received this message because you are subscribed to the Google Groups "Chromium HTML5" group. To post to this group, send email to chromium-ht...@chromium.org. To unsubscribe from this group, send email to chromium-html5+unsubscr...@chromium.org . For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.
