This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(From a developer on Google Docs:) Google Docs Offline has multiple appcaches. We have multiple caches because we have multiple editor applications (document picker, word processor, spreadsheet, presentation tool, drawing tool) each with its own javascript binary and release cycle. We also have various variants of each application. The variant used depends on various facts about the document being opened, each variant is suitable to open a wide class of documents. One ‘special’ cache has a fallback entry covering our entire domain. The application served in this cache is capable of examining the URL used by the user and selecting the right cache to use. It then redirects the user to a URL held in that cache. When the applications it contains is started, it uses the history API to change the apparent URL to match the one the user originally navigated to. The URLs in these caches are not ‘public’ URLs, they are known only to the launcher. The URLs users routinely open while online do not bind to any of these caches. We regularly examine the set of documents the solution has stored offline, calculate which set of caches is needed to open them, and manually update those caches.
We've discussed what an API to do this could look like, some notes are here... https://bugs.webkit.org/show_bug.cgi?id=67135
- api needs to be accessible in a window, worker, or shared worker context - getting the list of appcaches needs to be async - api needs to expose the manifest URL - should be possible to tell when a cache update was last attempted (staleness) - should be possible to force an update - should be possible to get events from such updates (and maybe if such an update is triggered while it's already running,, start getting the events from the previously-running update instance) - should be possible to decommission a cache - should be possible to create a new cache from manifest - we shouldn't use the actual .applicationCache object for representing the cache in the enumerated list, so that the app doesn't get confused if it finds events are already being fired on it I expect I'll add this via NavigatorStorageUtils, and add that to WorkerNavigator.
I think it's important to distinguish between aspects of this proposal which add convenience and those which add completely missing functionality. The hard core of this proposal from my point of view is: * Enumerate caches, get the manifest URL for each cache * Allow the deletion of caches by manifest URL The rest is useful, certainly, but can be achieved using iframe tricks already. I'd much rather have the two things above than see the proposal stall on the more ambitious items.
Given ServiceWorkers, we might end up punting on this.
Alex, do Service Workers provide the features described in comment 2 sufficient to satisfy the needs of David's team?
Yes, I believe that Service Workers do provide the requested flexibility. It's possible both to enumerate the cache objects and understand the state of the updated/waiting SW scripts using the provided API. These aren't 1:1 with the AppCache model, but combined I think they get you there.
Cool. Are the relevant APIs exposed outside the service worker? That was something David was saying would be quite useful, IIRC.
Serviceworker certainly has this use case covered, although not in the particular way described in this bug. Adding this back into AppCache wouldn't be worth it, as anybody attracted to manual cache management is certainly going to use service worker.
Roger. Marking this WONTFIX then.