W3C home > Mailing lists > Public > public-html@w3.org > September 2012

[Bug 19040] New: Suggestion for improved caching functionality in html5 specification

From: <bugzilla@jessica.w3.org>
Date: Tue, 25 Sep 2012 21:58:26 +0000
To: public-html@w3.org
Message-ID: <bug-19040-2495@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19040

           Summary: Suggestion for improved caching functionality in html5
                    specification
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: HTML5 spec
        AssignedTo: dave.null@w3.org
        ReportedBy: contributor@whatwg.org
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org,
                    public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org, jackalmage@gmail.com,
                    bhawkeslewis@googlemail.com, ayg@aryeh.name,
                    slgard@gmail.com


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

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 25 September 2012 21:58:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:34 UTC