On Thursday, December 11, 2014 10:45:26 AM UTC+9, Ehsan Akhgari wrote:
> On 2014-12-10 3:32 PM, Jonas Sicking wrote:
> >
> > I think instead the proposal is to enable a SW from website A to say
> > "please consult me for any network requests to https://a.com/apis/*";.
> >
> > Then if website B makes a network request to
> > https://a.com/apis/whatnot, it would first go to B's SW as per current
> > SW specifications. But if that SW decides to forward the request to
> > the network, then rather than directly hitting the network, first go
> > to A's SW.
> >
> > Same thing if B's SW for any other reason makes a network request to
> > https://a.com/apis/whatnot. Rather than directly hitting the network
> > as is currently defined, we'd first go to A's SW.
>
> Yes, that is exactly what I had in mind.
I would love to see something like this.
Third party services (e.g. Analytics, Fonts, Social) should be able to declare
that they have a Service Worker that will happily take care of the requests
that are relevant for them if the current site's SW (if any) let them through.
Failing that, we might see a proliferation of sites that go through the trouble
of offlining these third party services themselves in their quest of nailing
their own offline-first user experience. For Fonts, we'll loose on cache hit
opportunities since that site's SW will most likely put them in its same-origin
restricted Cache.
Also, letting these third party services take matters into their own hands
opens up interesting opportunities.
For instance, a Fonts service provider might want to use the background sync
API to regularly rationalize its Fonts cache:
- pruning infrequently used fonts
- prefetching popular fonts for a given market
- fetching the whole font after seeing several requests for bits of it via
dynamic subtyping or unicode-range (e.g. CJK fonts can be quite huge)
- mapping subset requests to the whole font there after
---
I think these use cases lead to the following requirements:
1. The third party service is able to tell the UA to install and optionally
activate right away its service worker from the client site
Naive strawman: the client site added a script tag pointing to the third
party's bootstrap JavaScript; the boostrap Javascript code calls
navigator.connect(url of third party's SW, {takeControl: true/(default:false)})
UA installs the SW if needed.
takeControl: true would activate the SW right away
2. The third party service is able to tell the UA that its SW is happy to take
care of in-scope requests that the client site's SW (if any) has decided to let
go through.
Naive strawman: an extra parameter (consulted... ahem, couldn't think of
anything better...) => navigator.connect(url of third party's SW, {consulted:
true})
3. The third party service is able to tell the UA that its SW is happy to take
care of in-scope requests that any client site didn't deal with (via a SW).
I *think* this is needed for the Fonts service use case where relevant
requests [1] might trigger before the third party bootstrap script has a chance
to run.
Naively, a previous call to navigator.connect(url, {consulted: true}) would
make that happen by default but I'm probably missing something important that
makes this a bad idea.
[1]: The link rel to the CSS containing the @font-face definition [a] and
perhaps the font itself (if consensus is reached on [b])
[a]: https://developers.google.com/fonts/docs/getting_started
[b]: http://lists.w3.org/Archives/Public/www-style/2014Nov/0593.html
PS: I'll try to join the F2F via VC if possible.
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
