#367: Periodic Background Sync
Discussions
2019-11-26
Ken: Some contraversy at TPAC - was wodnering if anything changed after TPAC
Yves: some will not implement it because of the privacy issues it will raise.
David: I think there has been a bunch of discussion in the rechartering of the serviceworkers working group.
Yves: this is not in the proposed charter.
Ken: Jake Archibald has wrote that it's blocked on privacy concerns in other engines.
https://jakearchibald.com/2019/service-workers-tpac/
... in some cases you can use background fetch instead of background sync.
Ken: it seems like the model for backhround fetch lets you cancel ... it seems like this ties into a UX problem - not visible to the user that it's happening. The web is good because things don't happen unless you know it's happening. [but this breaks this model.]
Peter: there's a valid use case going the other direction - a PWA when you're offline - you take a photo and then when you connect you sync.
HadleY; to those who commute e.g. offline on the tube - this makes a difference.
Yves: that could be done with a going online event
David: some of the concerns people have had is how some of these APIs have let sites run script in response to events. Some of the proposals have been you can run network activity but no script.
Peter: just updating your cache?
David: here's some stuff we want to upload / download.
Dan: [quesiton of whether you need this API to do sync when you go online]
Ken: serviceworker doesn't get activated for a "go online" event
Ken: the reading app, news app, ....
Dan: FT doesn't need this and they do it.
Ken: yeah but a lot of data , especially when roaming...
Hadley: podcast apps do this
Peter: workaround is a push notification - silent push - that triggers the update
Ken: All push notifications need to show UI, there are no silent push notifications
Peter: worth asking what the feedback from the origin trial has been.... Can someone write that query back to them
OpenedApr 29, 2019
Góðan dag TAG!
I'm requesting a TAG review of:
You should also know that... The spec is in review, so this is more of an opportunity to review the proposed API.
We'd prefer the TAG provide feedback as (please select one):