Rename allowOnBattery to chargingOnly?

[jakearchibald]

Or something else that gives us a falsey default.

I'm guessing something like chargingOnly was avoided because of devices that don't have a battery? I guess something like powerConnectedOnly avoids that.

[annevk]

chargingOnly has the opposite meaning, no? That seems more likely to be the problem.

[jakearchibald]

Deliberately so. allowOnBattery currently has a default of true. Picking an opposite allows the default to be false for the same behaviour.

It also closer matches what I've seen in beyondpod (Android podcast app), the option is "Download if charging only". That's a single data point though.

[annevk]

Oops, my bad. chargingOnly wfm. More bikeshed: excludeBattery, wiredOnly...

[jkarlin]

ACRequired? Would that be acRequired?

[jkarlin]

Yes, chargingOnly was avoided as it doesn't really make sense for systems without batteries.

[annevk]

stationaryPower? I agree with OP that defaulting to false is required, more important than semantics of the name we pick.

[jakearchibald]

I'm shying away from anything that involves "discharge" because ew. "wired" is ambiguous with network.

acOnly?

[jkarlin]

acOnly works for me.

[annevk]

"ac" stands for alternative current, right? That doesn't seem very timeless either. (I don't really care, but the reasoning doesn't seem consistent.)

[annevk]

preserveBattery.

[jakearchibald]

avoidBatteryUse? Although preserveBattery allows more UA control

[jakearchibald]

avoidBatteryDrain has wiggle too I guess

[Apeliotes]

If you want to avoid using the term BAttery since some devices don't have them, I'd suggest using "power" instead. PowerSaving or ConservePower maybe?

[annevk]

We want a term that indicates synchronization should not be performed when the devices has a finite power source and is also reasonably clear.

[jkarlin]

Such a difficult thing to name. acOnly and chargingOnly are my favorites so far, but each have issues.

Then there is the question of laptops. If it's set to acOnly should a laptop really not send the message until it's plugged in again? That seems extreme. I suppose the UA could lie and say that a laptop is always plugged in.

[annevk]

That is why preservePower or some such makes more sense. E.g. if a phone has more than 80% battery it might be okay to drain it a bit or not. Leaving those finer details up to the user agent and user preferences seems much better.

[jkarlin]

Periodic should default to charging, one-shot shouldn't. Not sure how we can make that false for both without changing the name for each, or simply not exposing the option to one-shot.

[KenjiBaheux]

Do we absolutely need a boolean option?

Could we have a 3 states option:

• the default: "auto" or undefined(?) = meaning the user agent should do what's best (e.g. periodic => charging, one shot => any power source assuming a reasonable battery level)
• A: specifically request that the sync happens when power comes from an infinite source
• B: specifically request that the sync happens regardless of power source

Hmm,

• powerConstraint: "auto", "stable", "any" ?

[annevk]

Different approach, what do we expect the UX for this to be? Are we going to communicate this to the user somehow without things getting overly complex?

[KenjiBaheux]

I imagine that we might to want to show these nuances in the context of a battery usage audit page.

We don't have a concrete plan yet so this is just my own attempt at one.
For a battery powered device, I imagine that this battery usage audit page would have the following features:

• a list of origins ordered by battery usage (highest to lowest).
• Selecting a particular origin would give more insights about how power is spent.
  • For instance, there would be a breakdown showing power consumed for active browsing vs. passive usage via APIs such as background sync, push notifications, geofencing...
  • For each APIs, the user would be able to revoke the permission or tweak triggering conditions (if relevant) to reduce power consumption.
    • For background sync, the UI would let the user choose between different power vs. convenience tradeoffs:
      • let the user agent do what's best
      • maximize power savings
      • maximum convenience of use

Approximately:

 Background sync: [allowed (| denied|)]

   power consumption: [ balance consumption vs. convenience  ]
                       | maximize power savings             |
                       | maximize convenience               |
                       ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

[annevk]

That makes sense. If we have that, I think exposing that level of granularity to the API seems about right as well. Which means we don't really have to worry about ac or batteries.

[jakearchibald]

@jkarlin

Periodic should default to charging, one-shot shouldn't.

Agreed. More reason to split the APIs.

@KenjiBaheux I like this. The user should be able to say "This origin should not be allowed to sync while battery is draining", "This origin should not be able to sync while on cellular".

I'd like to avoid .register failing if there's a clash between what the developer asks for, and what the UA enforces per user settings. So the options could be:

• networkType - "auto" or "avoid-cellular"
• powerStatus - "auto" or "avoid-draining"

…I can't think of a good one for idle.

"auto" means the UA can impose extra restrictions based on user settings, battery saving modes, roaming etc. The developer can only self-impose restrictions.

[jkarlin]

The draft periodic idl now has avoid-draining.