On Thu, Jul 7, 2011 at 3:57 AM, Karl Dubost <ka...@opera.com> wrote: > Felix, > > Le 29 juin 2011 à 05:27, Felix Halim a écrit : >> Suppose the content of the main page change very often (like news site). >> In this case, you don't want to cache the main page since the users >> want to see the latest main page, not the cached ones when they open >> the main page later. > > Is there a web site which exhibits exactly the issue you are mentioning. > Or could you set up a mini Web site exhibiting the issue. I have read the > full thread, and I still do not understand what you are trying to solve. HTTP > cache is about setting user interactions. There is no good values, just the > values you decide that would make sense. > > HTTP Cache can already handle a lot of cases (offline/online) without even > using AppCache, specifically when it is only content.
This is a real example. I build a site like: http://uhunt.felix-halim.net/id/339 That is is mine, and there is another ids like: http://uhunt.felix-halim.net/id/32900 http://uhunt.felix-halim.net/id/1133 And thousands of other IDs. Usually people look into few dozens IDs and not all thousands of them. Each ID has a large-unique-frequently-changing data attached to them (about 400KB). Obviously, if I do a clean separation, and store the static framework in AppCache, and the frequently changing data in localStorage, I can only cache 10 ids data or so. What I want is a 5MB "pageStorage" quota per page id. So that I can store the frequently changing data to it rather than the shared localStorage which uses the 5MB domain quota. In this case, any users can essentially view a lot more ids without having to worry exceeding the localStorage quota as long as I know that per page takes far less than 5MB. Of course I can implement my own cache revocation like deleting from localStorage for ids that are less viewed. But this job is best left to the browsers. Browsers can remove any page that is not viewed anymore and the pageStorage associated to it. Is that clear enough? on why we need pageStorage? Now the problem is, how do you use AppCache + pageStorage? They are conflicting each other in terms of URL. I can use AppCache to cache the static framework I have to URL like: http://uhunt.felix-halim.net/id Then a pageStorage can be created for each different hashbang: http://uhunt.felix-halim.net/id#339 That will give me 5MB for id = 339 And: http://uhunt.felix-halim.net/id#32900 That will give me ANOTHER 5MB for id = 32900 and so on. Then the browser can decide which URL are less frequently accessed and destroy the pageStorage associated to it if the browser has no space left. Even if my script is malicious and I create unlimited number of hashbang to get unlimited quota, the browser can just remove and store only let say 100 latest or most frequently used hashbang. So, should be perfectly fine to have pageStorage attached to a hashbang value. This will help in web application developers to cleanly separates the static from the dynamic and have nothing to worry about managing their cache replacement policies, or worry about the limitation of 5MB of localStorage or any other storage! This will also help the browser to dissect what's static and what's dynamic! It's a WIN-WIN strategy for all. I think everybody knows that if I directly use AppCache to this url: http://uhunt.felix-halim.net/id/339 What will happen? I will have to refresh twice to get the latest statistics of my page! Now, if somehow AppCache can make the main page ONLINE (that is, so that I don't need to refresh twice). Then, all the discussions of pageStorage above and quota becomes meaningless! So, my proposals is either to make the main page of the AppCache "ONLINE", or support pageStorage for hashbangs. Do you have suggestions on this? Felix Halim
