Re: [w3ctag/design-reviews] Periodic Background Sync (#367)

The discussion at TPAC focussed on one-off Background Sync Let's focus on Periodic Background Sync here.

1. Background Fetch is designed to handle long-running downloads and uploads that can't be serviced withint the execution time of a serviceworker event. They're also one-off, i.e., a new background fetch needs to be registered for each set of logical downloads. Because these can persist for long periods of time, across browser restarts, it's important to show persistent UI for the duration of background fetches.

Periodic Background Sync solves a different problem. It enables a website to get repeated opportunities for updating state and content after registration, provided there's ongoing user engagement with the site.

2. The way Chrome has implemented Periodic Background Sync, and the recommendation given in the spec is to cap the frequency of periodicSync events, and tie it in with user engagement with the origin. This means that if you stop using an installed PWA, we stop sending periodicSync events. The origin won't be able to keep consuming data and resources in that case.

3. Web Push requires developers to code up a server that speaks the Push protocol, in order to send updates. It also causes the browser to be woken up to service the push event whenever the developer thinks is appropriate. Periodic Background Sync is different in that it gives the control of when to allow sites to update, to the browser. This allows the browser to optimize resources by clubbing updates of various PWAs while being respectful of user choices such as Data Saving mode, and prioritizing apps the user engages with more in the usage of these resources. A happy side effect is that it's easier to use for developers than Web Push is.

Let me know if this answers your questions.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/367#issuecomment-559113041

Received on Wednesday, 27 November 2019 14:36:17 UTC