Þann fös 1.júl 2011 03:22, skrifaði Felix Halim:
I'm looking for a solution that doesn't require modifying anything
except adding a manifest.
I recommend fixing your website. As others have stated, this has
practical benefits, in the online as well as the offline case.
As I said before, separating dynamic from the static will work,
Great!
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.
Nobody's forcing you to use localStorage. How do you figure using
pageStorage or localStorage will be less work than using iframes or
other linking methods already proposed?
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.
Then specify the applicable HTTP headers with informative values. HTTP
caching hasn't stopped working, nor is it barred from improving. There
is space for implementations to improve while complying with current
specifications. All you have to do is split dynamic resources from
static, read the RFC and send the appropriate headers.
Of course this method has the drawback of requiring a request/response
pair for every resource transferred over HTTP.
So, it seemed that AppCache is a perfect fit...
AppCache is no magic bullet. Don't use it if you figure it isn't 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?
FYI, HTTP has already resolved this issue, by forbidding implementations
from returning a stale version by default under normal situations or
without warning
In this case, I better off NOT to use App Cache, since it brings the
old content everytime.
Right. Bad App Cache.
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!
I'm not following your line of thinking. Why do you insist on using an
App Cache for each page rather than a shared cache for all your resources?
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.
Are you certain that users wish to archive every single dynamic resource
they fetch from your site? Disposition of any significant amount of
storage should be in the hands of the user, if indirectly through the
user agent. Take handhelds.
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
And you're sure this is a good thing, because?
http://bla/page#!id=10
You *can't* allocate a quota per URI fragment, as a script in the page
could create new ones as wanted.
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.
Show how either the HTTP specification or common practice forbids HTTP
caches from satisfy your use cases.
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).
Caching the main page may be useful, so you'd have to implement both.
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.
You're asking for user agents archiving websites for offline viewing (in
the offline mode). I fetch a bunch of unread pages for offline reading
from time to time, but keeping a copy of read pages when I'm most likely
going to be online may be considered a waste of storage space. Users who
have a lot of storage at their disposal may do this already. I see no
reason to do so only if requested by the author.
There are two situations:
a) A user agent runs in a constrained environment with limited storage
space. The user agent caches static resources only, or doesn't cache at all.
b) A user agent runs in a plentiful environment with great volumes of
storage space at it's disposal. The user agent archives most if not all
resources it fetches, throwing stale resources away according to a cache
algorithm when a quote set in proportion to the available storage space
is reached.
How does your proposal help the user agent in archiving, or not
archiving resources?
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.
This requires a validation roundtrip (as is common), but is otherwise fair.
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").
HTTP caches may do what you want.
