W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > December 2010

[Bug 11548] Suggestion for improved caching functionality in html5 specification

From: <bugzilla@jessica.w3.org>
Date: Wed, 15 Dec 2010 09:15:14 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PSnS6-0006FQ-Tw@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11548

--- Comment #4 from Simon <slgard@gmail.com> 2010-12-15 09:15:14 UTC ---
What I meant by "in it's domain" is that javascript probably shouldn't be able
to modify the cached entries of non-same-origin documents.

Sorry to be vague about it, but I'm guessing you guys spend more time thinking
about cross-domain scripting vulnerabilities than I do :) 

Although now that I do think about it, this could surely be done quite safely
if the cache of the non-origin items were only viewable from the requesting
domain (if that makes sense?

> That's probably a feature not a bug.

I've no doubt it's deliberate, but it seems logical to me that the client
should be able to change it's mind and cache what it likes.

>Anyhow, if you really want to preserve image state without reference to the
>original resource, load it into a canvas bitmap and persist that.

I've thought about suggestions like that (such as converting the image data to
a base64 string) but I have 1000's of images that I'd like to cache. doing the
conversion for 1000's of images is likely to be slow and I'd probably end up
wanting a way to cache the base64 -> binary conversion :)

My question ultimately becomes, why can't javascript dynamically update the
manifest data?

Or making localStorage able to store binary data might be a more flexible
solution?

It would also be nice to allow apps to request more than the 2-5Mb of
localStorage that currently seems to be provided?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 15 December 2010 09:15:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 15 December 2010 09:15:32 GMT