[whatwg] AppCache-related e-mails

[Felix Halim]

On Fri, Jul 1, 2011 at 12:40 AM, timeless <timeless at gmail.com> wrote:
> It's possible to build a main page so that it can update its content
> using a subresource. You can use iframes, javascript (including json),
> xmlhttprequests, or other things to do this.

Those are another option besides using localStorage.
Again, those things requires restructuring your website.
I'm looking for a solution that doesn't require modifying anything
except adding a manifest.


> Nothing requires you to have a monolythic main page which is incapable
> of dynamically updating itself. ... If I visit your page on May 1st
> and sit there for two months, does your page really just want to
> continue to show me the same content when I glance at it on July 1st?
> It can show other content if it wants to, and in order to save
> bandwidth costs, it should avoid resending the framework which
> shouldn't be changing. Once your page works well for this case, it
> should work well for app-cache.

As I said before, separating dynamic from the static will work,
however, if we don't have "pageStorage", even we have a clean dynamic
separation, it will quickly run out of space if we use "localStorage"
since the localStorage quota is per domain.

Let's see an example:

I have a dynamic page with this url:

http://bla/page?id=10

The content inside is changing very frequently, lets say every hour.
Of course, I want the browser to cache the latest version.
So, it seemed that AppCache is a perfect fit...

I then add the manifest to enable the App Cache, and what do I get?

Everytime I open that URL every hour, I ALWAYS see the STALE version
(the 1 hour late version). Then few seconds (or minutes) later (depend
on when the AppCache gets updated), I refresh, then I got the latest
content. Annoying, right?

In this case, I better off NOT to use App Cache, since it brings the
old content everytime.

This is why most people says please "DON'T cache the main page".



Now, let see the alternative: I build a framework to separate the
dynamic from the static.
I have to make it so that only ONE MAIN PAGE get cached by the app cache.
So, my URL can NO LONGER BE:

http://bla/page?id=10

But it has to change to:

http://bla/page#!id=10

Why do I have to do this? it's because if I DON'T, then each page will
be stored on different App Cache, and the "stale by one" still occurs!
That is,

http://bla/page?id=10

and

http://bla/page?id=11

Will be on DIFFERENT AppCache!

In that case, my cleanly separated static and dynamic will have no effect!
Because all the statics get duplicated for each App Cache.
It will be the same as if I don't have the framework!

So, to make the AppCache only cache one static framework, I have to
make my page such that it is served under ONE url:

http://bla/page

Then take the "#!id=10" as non url (or ajax bookmark). This way, the
AppCache will only cache ONE of my static framework, and MANY dynamic
content inside it.

Guess what? All the incoming links from other blogs are now broken!
Of course I can make a redirect, but redirect is AGAINST making the web faster!

I think Facebook did the #! thing a while ago, then they abandoned it, why?

Ok now I'm happy with my framework and the redirect, and guess what?
Soon, I have other pages with #!id=11, #!id=12, ...,  #!id=10000.
All of them are important and I wan't to cache them and I uses the
localStorage (or indexedDB) to cache the dynamic content of those
pages.
Note that even though the dynamic content is "dynamic" it doesn't mean that:

http://bla/page?id=10

has "shared" data with

http://bla/page?id=11

It can be totally different unrelated dynamic content. id=10 dynamic
content is entirely different from id=11 dynamic content. However,
since I use localStorage to cache the dynamic content, ALL OF THEM are
limited to the quota of my domain. My 5MB localStorage domain quota
will quickly run out of space.

If only I can store the dynamic content into a pageStorage (assuming
different URL -> including the shebang bookmark has different
pageStorage), then I won't be running out of storage if I keep one
page within 5MB. So

http://bla/page#!id=10

has 5 MB pageStorage quota, and

http://bla/page#!id=11

also has 5 MB pageStorage quota, etc...

Then I would be very happy with the new framework.
Since it will store very compact static App and very compact dynamic content.
It's a win win for everyone, nothing is wasted.

But, if I don't have pageStorage quota, my beautifully separated the
dynamic from the static framework will be useless since the
localStorage DOMAIN QUOTA will kill me.


So, we have seen how the AppCache fails to satisfy certain usecase and
how pageStorage is needed to make the alternative solution works.

Here, I propose a solution:  AppCache should COMPLEMENT HTTP Cache so
that "the main page is not cached" (you know this is not literally
what it means).

With that solution, I don't have to do ANYTHING on my original site to
make it work (except adding a manifest to my original page). I can
still use the old url:

http://bla/page?id=10

It will cache AND SHOW the latest page to the users (just like normal
web page with HTTP Cache). Then will show the latest cache if the
network or the server is offline (and perhaps give notification
header). That's ALL I NEED. This guarantees that my website will still
be available when the user goes offline.


All these discussions only begs to add one feature to AppCache:
- Only show the cache when the network / server is offline, otherwise,
show the online version of the page.

The current AppCache doesn't care whether the network/server is online
or offline, it BLINDLY shows the cache everytime. This is good for the
default, however, we should HAVE an option to not show the cache if we
are ONLINE (this is what people meant when they say "DON"T CACHE THE
MAIN PAGE").

Felix Halim