[Bug 14364] Add an API to make appcache support caching specific URLs dynamically

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14364

Louis-Rémi <louisremi@mozilla.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|NEEDSINFO                   |

--- Comment #4 from Louis-Rémi <louisremi@mozilla.com> 2011-10-24 19:52:37 UTC ---
(In reply to comment #3)
> Yeah we're definitely not using data: for this.
> 
> 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: Did Not Understand Request
> Change Description: no spec change
> Rationale: What are the use cases for making appcache dynamic? (I'm not saying
> there aren't any, I just need to know what they are to design the solution for
> them.)

Granted, using data isn't the best option.

I've written an extensive blog post about the use cases for a dynamic appcache:
http://www.louisremi.com/2011/10/07/offline-web-applications-were-not-there-yet/

tl;dr: if you build an rss reader with checkbox to make articles available
offline, it's easy to store/delete the text content of the article at will
using localStorage or indexedDb, but it's impossible to store/delete associated
images (and sounds/videos). You could dynamically generate a cache manifest for
all "offline enabled" articles, but the client would have to re-download all
resources every-time the manifest is updated, as you know. (and you can't store
images as data-uris, since they come from different origins)

Mozilla implemented a simple "OfflineResourceList" API which solves that
problem by enhancing applicationCache with "add()" and "remove()" methods.
This is the kind of solution I am looking for, although "add" is a confusing
name, since it should be able to update a particular resource too.

There is a risk that this API could cause confusion amongst web developers.
Should they use a cache manifest or abandon it completely in favor of the JS
API? I believe the cache manifest should be advocated to be used for the
application structure+presentation+logic (HTML, CSS, JS), while the dynamic API
should be used for the application *content* (medias, xml, json).

-- 
Configure bugmail: http://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 Monday, 24 October 2011 19:52:43 UTC