Periodic Background Sync: new spec or part of the BackgroundSync spec?

[mugdhalakhani]

An explainer has been added to this repo for Periodic Background Sync here:
#154

Some concerns have been raised about having two similar capabilities -- BackgroundSync and Periodic BackgroundSync. The proposal is to keep periodicsync capability and get rid of the one-off sync capability, because that can be done using existing APIs, for instance, Background Fetch. It might be more future-proof to thus have a separate spec doc for Periodic Background Sync.

Thoughts/feedback is welcome.

[jakearchibald]

I'm not against deprecating one-off sync if the user-cases are met by background fetch, but we'd have to look at usage numbers can handle deprecation carefully. I think one-off sync has pretty decent usage, right?

[jerrygreen]

I think it's two absolutely different things, and it's confusing they both named "background-sync".

I personally thought that I may use "backgound-sync" to periodically update data on the device, so it can stay up-to-date pretty much always, and when user accesses it offline, - it's not outdated. Like, if I may sync something in background anyway, why wouldn't I sync it once in a while?

But turns out "background-sync" is not exactly the thing I imagined, as I later understood...

"background-sync" is meant for:

• Upon a failure sending user message to a server (due to being offline), add the message to a special background queue, and try sending it again when the network will appear

"periodic-background-sync" is meant for:

• Updating app data in background once a while

And after understanding of these cases, I concluded that "background-sync" is pretty much useless feature, and it's shame it took this short "background-sync" name. Let me explain: I think it's much better UX to simply cache user message upon failed request, so it will never be lost upon closing the application, and when network is accessible again, user might easily try sending it again from application UI. So this "retry" is explicitly on user behalf! It's weird UX to try sending his message in background, since he might never know if transaction was successful or not, can't even be sure that background-sync actually worked. Not to mention he might not even want to send this message later, i.e. "either now or never" situation. It all might may sound good when things are about milliseconds or few seconds of network unavailability, but we're talking here about whole minutes and potentially hours of connection lost. That way "background-sync" is not just useless but even potentially harmful feature. Bad UX.

While that, "periodic-background-sync" is exactly the thing I imagined when I first heard about "background-sync".

In the end, I think that "background-sync" should be actually deprecated, in order to not propagate harmful UX.

While "periodic-background-sync", despite having longer name, should persist its longer name (in order to not be confused with harmful "background-sync" that should be deprecated), and actually be implemented.