[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