Intent to Ship: Cache API for Service Worker

290 views
Skip to first unread message

Kenji Baheux

unread,
Oct 28, 2014, 3:34:14 PM10/28/14
to blink-dev

Contact emails

kenji...@chromium.org, jsb...@chromium.org


Spec

Editor’s draft (W3C First Public Working Draft)


Summary

The Cache API for Service Worker consists of additional ServiceWorker APIs which allow authors to fully and conveniently manage their content caches for offline use. An origin can have multiple, named Cache objects, whose contents are entirely under the control of Service Worker scripts. One noteworthy edge that the Cache API has over the polyfill approach is its ability to handle opaque response.


We're proposing to ship a subset of what is defined in the spec (see this document for more details).



Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/Du9lhfui1Mo/HxL_pS7Cl-AJ

The spec and project used to be called Navigation Controller, but the name was changed to Service Worker. 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.


Demo link

This is essentially the same demo featured in our Service Worker intent to ship (the demo uses a polyfill and is being updated to let native Cache APIs take over when available).


Debuggability

Developers can check the existence of caches and peek inside manually by inspecting the relevant Service Worker and issuing commands via the console.


Compatibility Risk

Pluses and minuses:

+ There's a first public working draft of the spec.

+ Mozilla is implementing Service Workers in Firefox, see bug 940273.

+ We semi-regularly reconcile the spec and our implementation. We have a defined process for that.

+ The team has been writing W3C testharness.js tests which we plan to upstream to W3C.

+ All the relevant closed or decided cache spec issues are tracked at crbug.com and triaged to minimize compatibility risk (unresolved impact MVP = 0; closed not tracked = 0; decided not tracked = 0; untriaged or unresolved = 0)

+ Based on observations from the spec issue triaging process, we believe that the scope of this intent to ship is fairly stable.

- We could not find any relevant tests in Firefox’s maple branch to cross check our Cache API implementation against

- The spec is under active development


OWP launch tracking bug?

http://crbug.com/425426


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/6461631328419840



Ben Kelly

unread,
Oct 28, 2014, 4:19:30 PM10/28/14
to Kenji Baheux, blink-dev
> From: "Kenji Baheux" <kenji...@chromium.org>

> - We could not find any relevant tests in Firefox’s maple branch to cross
> check our Cache API implementation against

Our Cache tests are currently limited, but you can find what we have here:

http://hg.mozilla.org/projects/maple/file/4a0fdfe4bd74/dom/tests/mochitest/cache

> + The team has been writing W3C testharness.js tests which we plan to
> upstream to W3C.

Are these available anywhere yet? I would love to try them out against what I have for gecko.

> + Based on observations from the spec issue triaging process, we believe
> that the scope of this intent to ship is fairly stable.

It seems that the main API is stabilizing, although there are a number of async interaction corner cases that are not spec'd.

I think a shared/common test suite would help mitigate any risk from these spec gaps.

Just to clarify, you're only going to be exposing Caches on the ServiceWorker global for now, right?

Thanks!

Ben

Kenji Baheux

unread,
Oct 28, 2014, 4:32:07 PM10/28/14
to Ben Kelly, blink-dev
Our Cache tests are currently limited, but you can find what we have here:

  http://hg.mozilla.org/projects/maple/file/4a0fdfe4bd74/dom/tests/mochitest/cache

Thanks, highly appreciated.
I'll test our implementation against these and report back with results as soon as possible.
 

Are these available anywhere yet?  I would love to try them out against what I have for gecko.

More tests might land but everything will be available here (all the tests prefixed by cache-).

 
Just to clarify, you're only going to be exposing Caches on the ServiceWorker global for now, right?

Yes, we only intend to expose Caches on the ServiceWorker global for now.

Ben Kelly

unread,
Oct 28, 2014, 5:30:12 PM10/28/14
to Kenji Baheux, blink-dev
> From: "Kenji Baheux" <kenji...@chromium.org>

> >
> > Our Cache tests are currently limited, but you can find what we have here:
> >
> >
> > http://hg.mozilla.org/projects/maple/file/4a0fdfe4bd74/dom/tests/mochitest/cache
>
>
> Thanks, highly appreciated.
> I'll test our implementation against these and report back with results as
> soon as possible.

So this may be difficult depending on where you have exposed things. Our current tests are written using Caches available on window and dedicated worker globals (using prefs to control access).

Similarly, I had difficulty running the blink tests because they use real ServiceWorkers (as you would expect). Unfortunately, I'm hitting issues in our SW implementation preventing the cache related code from even running.

I'll see if I can hack it a bit to run just the cache related bits tomorrow.

Thanks!

Ben

Ben Kelly

unread,
Oct 29, 2014, 10:42:15 AM10/29/14
to Kenji Baheux, blink-dev
> From: "Ben Kelly" <bke...@mozilla.com>
Actually, the problem I was having was just with how I copied the tests into our test harness. I have the tests running now.

Unfortunately, though, the tests have revealed a bug in my implementation in gecko. Right now I'm incorrectly draining the Request body data on Match(). This is causing lots of failures since the tests reuse some Request objects for matching purposes.

I'll work on getting these tests green in gecko.

Thanks again for pointing me to them!

Ben

Ben Kelly

unread,
Oct 29, 2014, 6:33:16 PM10/29/14
to Kenji Baheux, blink-dev
Kenji,

I finally get the blink tests running against gecko's maple development branch. I need to look at the results a bit more closely, but I did have one question so far.

In the cache-match.html test I see that it expects to be able to store responses for these three requests separately:

cat: {
request: new Request('http://example.com/cat'),
response: new Response('')
},

cat_with_fragment: {
request: new Request('http://example.com/cat#mouse'),
response: new Response('')
},

cat_in_the_hat: {
request: new Request('http://example.com/cat/in/the/hat'),
response: new Response('')
}

The URL attribute on Request, however, is supposed to ignore fragments as far as I can tell.

https://fetch.spec.whatwg.org/#dom-request-url

So shouldn't storing new Request('http://example.com/cat#mouse') be identical to new Request('http://example.com/cat')? Shouldn't this result in the second request/response pair overwriting the first pair?

In particular, this test seems wrong to me:

prepopulated_cache_test(simple_entries, function(cache) {
return cache.matchAll('http://example.com/cat',
{prefixMatch: true})
.then(function(result) {
assert_array_equivalent(
result,
[
simple_entries.cat.response,
simple_entries.cat_with_fragment.response,
simple_entries.cat_in_the_hat.response
],
'Cache.matchAll should honor prefixMatch.');
});
}, 'Cache.matchAll with prefixMatch option');

Sorry if I'm missing something obvious. Thanks for the help!

Ben
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Ben Kelly

unread,
Oct 30, 2014, 5:14:13 PM10/30/14
to Kenji Baheux, blink-dev
> From: "Ben Kelly" <bke...@mozilla.com>
> Kenji,
>
> I finally get the blink tests running against gecko's maple development
> branch. I need to look at the results a bit more closely, but I did have
> one question so far.

I spoke with Joshua on IRC about a couple test issues including this one. He pointed out that they are currently not run since MatchAll() is not implemented yet. Sorry for not catching that earlier.

Based on his suggestion I wrote up the issues as bugs:

https://code.google.com/p/chromium/issues/detail?id=428965
https://code.google.com/p/chromium/issues/detail?id=428970

If I find anything else I'll write them up as well. I'll only post here if they effect things that blink expects to PASS.

Thanks again.

Ben

Jochen Eisinger

unread,
Nov 6, 2014, 12:17:19 PM11/6/14
to Ben Kelly, Kenji Baheux, blink-dev
it makes sense to ship a MVP version of the cache api together with the service worker, so lgtm

Chris Harrelson

unread,
Nov 6, 2014, 12:54:19 PM11/6/14
to Jochen Eisinger, Ben Kelly, Kenji Baheux, blink-dev
LGTM

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Philip Rogers

unread,
Nov 6, 2014, 2:58:12 PM11/6/14
to Chris Harrelson, Jochen Eisinger, Ben Kelly, Kenji Baheux, blink-dev
This API makes sense, is a win for users, and has clear support from other vendors. LGTM

I don't like useless process but I think the remaining parts of the API could use a second intent to ship when we're ready to ship them.
Reply all
Reply to author
Forward
0 new messages