Intent to Implement: Background Sync
Kenji Baheux
Contact emails
Engineering: jka...@chromium.org*, icle...@chromium.org, gav...@chromium.org
* also spec editor
Spec
https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md.
Summary
A new API that extends Service Workers with an onsync event and associated registration API.
Motivation
Web applications with heavy client-side logic often need to synchronize data with a server. This need is exacerbated by new offline capabilities offered by Service Workers that will enable applications to run while disconnected entirely from the server.
Consider the case of a Twitter client. Who can say when 140 characters of genius will strike? In that moment it's clearly preferable for a Twitter client to provide a "send later" button in cases where sending doesn't initially succeed (e.g., while offline).
Periodic content updates are also important to improve the performance and responsiveness of a web app. Consider a news site that wants to sync the latest articles at night while the device is charging so that they're ready for the reader’s morning train commute.
The web currently lacks any ability to provide this sort of functionality in a user-friendly or power-efficient way. Current approaches require an application (or tab) to be running and rely on slow, battery-intensive pings. More details can be found in our use cases document.
Compatibility Risk
To minimize compatibility risk, we fully intend to work with interested parties to refine the API (issue tracker). In fact, We are already in touch with Mozillians and we will do our best to seek further third party involvement (e.g. interested parties from other browser vendors, web developers working on products with a need for the use cases).
Ongoing technical constraints
Implementation for our desktop platforms should be relatively non-intrusive due to Chrome’s existing ability to run in the background (i.e. background pages). The Blink changes will be in a new module, much like push messaging. The scheduling and persistent storage will be in Chromium content (storage will be in content::ServiceWorkerStorage and triggering the sync event will happen through the content::ServiceWorkerVersion class).
On Android, we expect to take advantage of the JobScheduler API for Lollipop and beyond. On pre-Lollipop Android version, we are investigating different solutions. You can find more details in this in-progress design doc.
We’ve already started to discuss potential concerns with the privacy team and have a broad agreement on the requirements.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes, with the exception of WebView (because of this limiting factor).
OWP launch tracking bug?
https://code.google.com/p/chromium/issues/detail?id=449443
Link to entry on the feature dashboard
https://www.chromestatus.com/features/6170807885627392
Requesting approval to ship?
No.
Philip Jägenstedt
> email to blink-dev+...@chromium.org.
