Intent to Ship: Cache Storage API for Service Worker
Kenji Baheux
Contact emails
Engineering: jsb...@chromium.org
Spec
Editor’s draft (W3C Public Working Draft)
Summary
The Cache Storage API* allows authors to fully and conveniently manage their content caches for offline use. The Cache Storage API is already available within a ServiceWorker context. This Intent to Ship is for exposing it globally.
*: we’ve used the term “Cache API” in our original intent to ship but we thought it was slightly too generic and might lead to unintended association with the “HTTP Cache” (i.e. the API doesn’t let you directly interact with the actual HTTP cache).
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/Du9lhfui1Mo/HxL_pS7Cl-AJ
See also the Service Worker intent to ship.
Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes.
Debuggability
Developers can check the existence of caches and peek inside manually by inspecting the relevant Service Worker and issuing commands via the console.
Caveat (on-going): the inspector is not yet hooked up for pages. We expect that it will be ready in time for the branch cut.
Compatibility Risk
Pluses and minuses:
+ There's a third public working draft of the spec (published in February).
+ Mozilla is implementing Service Workers and the associated Cache Storage API in Firefox, see bug 940273.
- The spec is under active development
+ However, the Cache Storage API section of the spec is pretty stable (no significant changes since our initial intent to ship)
+ No additional Cache Storage API surface as part of this intent to ship.
+ Data indicates that exposing the Cache Storage API to the global scope is reasonably safe (e.g. collisions with id=caches)
OWP launch tracking bug?
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5072127703121920
kenji...@google.com
Philip Jägenstedt
from the spec:
partial interface Window {
readonly attribute CacheStorage caches;
};
Philip
> email to blink-dev+...@chromium.org.
Benjamin Kelly
+ Mozilla is implementing Service Workers and the associated Cache Storage API in Firefox, see bug 940273.
Dimitri Glazkov
Alex Russell
Glad to see this going out.
Where is the collision data?
Jake Archibald
Really excited about this, it removes the needs for some hacks and opens the door for future use cases. Here are the immediate benefits:
A page getting potentially stale content from the cache, then updating that content if newer data can be fetched from the network, is a pattern (http://jakearchibald.com/2014/offline-cookbook/#cache-then-network) I expect to be common, as it's already common in native apps. Currently you have to make a request with some sort of signal that you want it to come only from the cache (https://github.com/jakearchibald/trained-to-thrill/blob/3291dd40923346e3cc9c83ae527004d502e0464f/www/static/js-unmin/index.js#L70), which you later pick up in the ServiceWorker (https://github.com/jakearchibald/trained-to-thrill/blob/3291dd40923346e3cc9c83ae527004d502e0464f/www/static/js-unmin/sw/index.js#L61). With caches on the page, this hack isn't needed, and the page can get the cached content straight from the cache.
Also, trained-to-thrill (https://jakearchibald.github.io/trained-to-thrill/) dynamically caches data from Flickr but the first set of data (API response and images) arrives before the SW has taken over the page. This means there isn't really an offliine-with-data experience until the page has been loaded twice. One solution is to avoid making the API and image request until the SW gets to call clients.claim(), but this comes with a performance penalty by delaying the start of these requests. With caches available from pages, the uncontrolled page can add the API response and images to the cache even before the ServiceWorker installs.
Another pattern is to allow the user to control the content they want to make available offline (http://jakearchibald.com/2014/offline-cookbook/#on-user-interaction) via some kind of "read later" or "save offline" button. Currently, when the user clicks this you have to postMessage to the ServiceWorker so it can deal with the cache. With caches on pages, this postMessage dance isn't needed.
Sites that have partial and dynamic offline capabilities (like the previous example) may wish to style links differently that lead to cached resources, or there's cached API data to construct that page. This is especially useful when navigator.onLine is false. With caches available from pages, the page can look up this data and apply classnames to appropriate links. Currently you have to postMessage the ServiceWorker, or use fetch() as a hacky messaging request/response system.
I'll make a Canary version of trained-to-thrill to show off these features as they land, along with an article explaining the benefits.
\o/
LGTM2.:DG<
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.> email to blink-dev+unsubscribe@chromium.org.
TAMURA, Kent
Software Engineer, Google