[whatwg] Unlimited pageStorage for App Cached web pages

Bjartur Thorlacius svartman95 at gmail.com
Mon May 30 07:39:47 PDT 2011


Þann mán 30.maí 2011 03:42, skrifaði Felix Halim:
> Hmm.. yes, I think "unlimited" is a bad word (I just use it because
> currently App Cache quota is unlimited).
>
> Let me explain my need for pageStorage in a different way:
>
> Suppose I have a web page and want to store it in an App Cache. This
> web page requires a few resources (.ccs, .js, images, etc..). But all
> of them are "static" resources. I want to store "dynamic" resources as
> well for that particular page only (not shared). Think of  the dynamic
> resources as "data" that changes from time to time for that particular
> page only. localStorage can be used to store the "dynamic" resources,
> but localStorage has very limited quota and it is shared to the entire
> domain. Different unrelated pages in the same domain will use the
> shared quota!
>    
The following is how I understand your requirements; please correct me 
where correction is due.
You've got two types of resources:

   1. static resources, to be retrieved once and cached indefinitely
   2. dynamic resources, to be updated whenever possible while always
      keeping the last version

The former is easy to achieve, but user agents tend to throw away stale 
versions as to not present outdated information to the user and to save 
storage space.
You want user agents to fetch the latest version whenever possible, but 
keep an old copy for when your servers are unreachable.
> Currently I can "hack" the App Cache to simulate the pageStorage like this:
>
> We can turn one of the .js files "dynamic" by updating the .js file,
> then edit the MANIFEST file a bit, so that the browser re-download
> *ALL* the resources again.  This way, the .js file quota gets in the
> App Cache quota which is currently *UNLIMITED*. But this "hack" is
> very costly, and inconvenient.
>    
5MB ought to be enough for anyone.
If all you want to do is store mutable resources for offline use and 
validate them if possible, but returning the cached entry (or entity) if 
validation is impossible, simply serve the resources with an Expires 
header set to a date in the past. That way caches SHOULD validate the 
response before reusing it, but may reuse it without validation under 
abnormal situations, such as when working offline. Of course, doing this 
for all resources doesn't make sense when storage space is scarce. In 
that case discard  stylesheets, huge videos, heavy graphics other files 
with a high noise to content ratio.*
If your (or your client's) cache doesn't do that already, you're free to 
modify it, or pay someone to do it for you.

*Warning: The result of calculating the noise to content ratio of CSS 
files is undefined.



More information about the whatwg mailing list