Bug 19040 - Suggestion for improved caching functionality in html5 specification
Suggestion for improved caching functionality in html5 specification
Status: RESOLVED LATER
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec
unspecified
PC Linux
: P2 major
: ---
Assigned To: This bug has no owner yet - up for the taking
HTML WG Bugzilla archive list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-25 21:58 UTC by contributor
Modified: 2012-09-25 22:26 UTC (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description contributor 2012-09-25 21:58:26 UTC
This was was cloned from bug 11548 as part of operation LATER convergence.
Originally filed: 2010-12-14 13:22:00 +0000
Original reporter: Simon <slgard@gmail.com>

================================================================================
 #0   Simon                                           2010-12-14 13:22:49 +0000 
--------------------------------------------------------------------------------
Sorry to bother you. I've never attempted to contribute to the html specification before, so I'm not sure I'm going about this the right way?

I'm in the process of developing a html5 app and have run into a problem that I think seriously threatens the usefulness of html5 as a platform for building applications.

Essentially, the lack of an api call along the lines of .add_to_cache(url, expires) seems like a glaring omission and means that I can't (for example) have some javascript dynamically generate links to images and have those images cached locally.

Here is a link to a question from someone else having the same problem
http://stackoverflow.com/questions/3476864/html5-iphone-dynamic-caching-of-images
There seem to be many people with similar issues.
================================================================================
 #1   Tab Atkins Jr.                                  2010-12-14 15:58:59 +0000 
--------------------------------------------------------------------------------
(In reply to comment #0)
> Essentially, the lack of an api call along the lines of .add_to_cache(url,
> expires) seems like a glaring omission and means that I can't (for example)
> have some javascript dynamically generate links to images and have those images
> cached locally.

There are many ways to force a caching opportunity.  For example, you could just create a bunch of images in javascript.  You don't need to add them to the document, just create them and set their src.  They'll be downloaded and cached as appropriate.  You can do this with *any* GETable resource, not just images.
================================================================================
 #2   Simon                                           2010-12-14 16:34:41 +0000 
--------------------------------------------------------------------------------
thanks for the response.

yes, but then caching policy is controlled purely by the cache header sent by the server? 

If that's a server I don't control -in this specific case twitter.com- there doesn't seem to be anything I can do about the lack of caching.

I wouldn't dream of a change to the html spec to solve my specific problem with a specific website :) but it just seems that javascript ought to have the ability to dynamically change what gets cached within it's domain?
================================================================================
 #3   Benjamin Hawkes-Lewis                           2010-12-15 00:47:59 +0000 
--------------------------------------------------------------------------------
(In reply to comment #2)
> yes, but then caching policy is controlled purely by the cache header sent by
> the server? 
>
> If that's a server I don't control -in this specific case twitter.com- there
> doesn't seem to be anything I can do about the lack of caching.

That's probably a feature not a bug.
 
> I wouldn't dream of a change to the html spec to solve my specific problem with
> a specific website :) but it just seems that javascript ought to have the
> ability to dynamically change what gets cached within it's domain?

What do you mean by "it's domain", and why should it have that ability?

Anyhow, if you really want to preserve image state without reference to the original resource, load it into a canvas bitmap and persist that.
================================================================================
 #4   Simon                                           2010-12-15 09:15:14 +0000 
--------------------------------------------------------------------------------
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?
================================================================================
 #5   Ian 'Hixie' Hickson                             2011-01-11 19:08:05 +0000 
--------------------------------------------------------------------------------
localStorage can store binary data per spec, it's just not implemented yet.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: none yet
Rationale: We actually used to have an API to add things to the appcache, but we removed it in a simplification sweep a while back. I expect we'll add it back in a future version once browsers reliably implement what we have so far. We don't want to run away from the browsers adding too many features, though, or interoperability will suffer as they each pick their own bit to implement and ignore the rest.
================================================================================