[whatwg] AppCache-related e-mails

?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.

Received on Friday, 1 July 2011 17:14:39 UTC