[whatwg] AppCache-related e-mails

[Felix Halim]

On Thu, Jul 7, 2011 at 3:57 AM, Karl Dubost <karld at 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