Contact emails
m...@chromium.org, owe...@chromium.org, kenji...@chromium.org
Summary
Foreign Fetch is a proposal to enable service composition via third party service workers (see the Intent to Implement for sample use cases). Link rel=serviceworker will allow these service workers to bootstrap themselves using Link headers in HTTP responses, specifically without this header, a service would have to rely on being embedded in an iframe to install its foreign fetch service worker (this experiment also enable installation of service workers through the <link> element, although that part doesn't enable anything the service worker javascript API doesn't already support).
Even though these really are two independent features, it still seems sensible to combine them into one origin trial as the Link header makes foreign fetch a lot more powerful (and without foreign fetch there isn't that much benefit in using the Link header or element to install service workers rather than just using the existing JavaScript API).
Explainer
https://github.com/slightlyoff/ServiceWorker/blob/master/foreign_fetch_explainer.md
Spec
Foreign fetch is defined in the Fetch and service worker specs. More precisely, HTTP Fetch in the fetch spec calls out to Handle Foreign Fetch in the service worker spec. Also see the definition of the InstallEvent in the service worker spec for the API to register for foreign fetch.
Link rel=serviceworker:
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#link-type-serviceworker
The current implementation of foreign fetch in Chrome has a couple of temporary limitations:
First of all any request for which CORS would send a preflight request isn't interceptable by foreign fetch.
In addition to that Chrome won't fall back to the network either if a foreign fetch event is dispatched but not handled.
Both of these are caused by complications around the way CORS is implemented in Blink. Part of the goal of this experiment is to determine if it is worth the significant engineering effort to refactor the CORS code to lift these limitations.
Link to “Intent to Implement” blink-dev discussion
Foreign fetch: https://groups.google.com/a/chromium.org/d/msg/blink-dev/EecwKDQoNtk/i57bp1GrCAAJ
Link rel=serviceworker: https://groups.google.com/a/chromium.org/d/msg/blink-dev/HwDRVyP505Q/tgEJY5kYCwAJ
Goals for experimentation
First of all we'd like to figure out if this API is actually as useful as we imagine it could be, and to get a better idea how this API will be used. Part of this we hope to learn from feedback from websites using the trial, but we'll also collect metrics around how the API ends up being used (do websites intercept requests from all origins, or some limited subset of origins; how many sub-scopes does a service worker typically register for, maybe we can get rid of sub-scopes entirely, etc).
A second goal would be to determine if the current performance characteristics of the API are acceptable, and if not, what areas in particular need to be improved upon. To get some idea about this we'll be collecting various performance related measurements with regard to event dispatching, service worker overhead for foreign fetch, number of affected page loads, etc. This should help us decide what if any limitations that aren't already in place might need to be put in place to make this API more performant, while still addressing the use cases we care about.
Experimental timeline
Enabled:
August 25th: Chrome 54 Branched to Dev.
October 18th: Chrome 54 Stable*.
November 17th: Chrome 56 Branch to Dev.
4 weeks of 54 stable channel feedback.
December 6th: Chrome 55 Stable*.
~6 weeks after Chome 56: Chrome 57 Branch to Dev.
10 weeks of 54 stable channel feedback.
4 week of 55 stable channel feedback
January 31st 2017: Chrome 56 Stable*.
Disabled:
~6 weeks after Chome 56: Chrome 57 Stable*. Initial experiment terminates.
* Stable dates are estimates: https://www.chromium.org/developers/calendar.
Any risks when the experiment finishes?
Even with foreign fetch there is no guarantee that any particular request will end up being intercepted by a third party's service worker. For example, under storage pressure we could evict the service worker and all storage for an origin using foreign fetch. Sites trying out this experiment should therefore be able to deal with things stopping working anyway.
Of course if foreign fetch is used to enable offline functionality, but the third party service worker doesn’t sync the data to a server then there is increased risk for the data to become unavailable after the experiment finishes, beyond the existing risk due to the storage pressure issue mentioned above.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
All except Android WebView (Origin Trials aren't supported on Android WebView).
OWP launch tracking bug
Foreign fetch: https://code.google.com/p/chromium/issues/detail?id=540509
Link rel=serviceworker: https://bugs.chromium.org/p/chromium/issues/detail?id=582308
Link to entry on the feature dashboard
Foreign fetch: https://www.chromestatus.com/feature/5684130679357440
Link rel=serviceworker: https://www.chromestatus.com/features/5682681044008960Summary
Even though these really are two independent features, it still seems sensible to combine them into one origin trial as the Link header makes foreign fetch a lot more powerful (and without foreign fetch there isn't that much benefit in using the Link header or element to install service workers rather than just using the existing JavaScript API).
On Tue, Aug 9, 2016 at 9:59 PM, Marijn Kruisselbrink <m...@chromium.org> wrote:Summary
Even though these really are two independent features, it still seems sensible to combine them into one origin trial as the Link header makes foreign fetch a lot more powerful (and without foreign fetch there isn't that much benefit in using the Link header or element to install service workers rather than just using the existing JavaScript API).
The header is very useful without foreign fetch too. The discussions seem to have been closed; are there standing concerns that prevent us from just shipping it?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
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+...@chromium.org.
LGTM2
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Contact emails
[ed: snip]