On 2015-01-07 3:34 AM, kenjibah...@chromium.org wrote:
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.
I'm happy to hear someone inside Google is interested in this as well!
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
Agreed.
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
I thought that navigator.connect() as envisioned by
<https://github.com/mkruisselbrink/navigator-connect> is about letting
websites communicate to SWs, not let them register one. It seems like
#1 above is about registration. Is there any reason to not extend the
existing SW registration mechanism?
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})
I'd argue that when the SW for site A lets a request for site B to go to
the network, we should consult B's SW (or a special cross-origin
handling SW from B) if one is present before going to the network by
default.
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).
Isn't this the same thing as #1?
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.
Well, we only have this problem if the embedding website triggers the
registration as well. I think we can avoid the issue if we let that
website handle its own registration in the normal way.
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.
I'm still struggling to understand what exactly navigator.connect() as
proposed does. :-)
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
