More API breakage: battery.remaining_time

[Danny Kukawka]

On Sunday 21 January 2007 23:58, Richard Hughes wrote:
> On Sun, 2007-01-21 at 23:24 +0100, Danny Kukawka wrote:
> > And what is the problem?
>
> It breaks the abstraction. When property values are changed
> non-atomically due to BIOS delays, session code breaks.

Sorry, but I don't see the problem, at least we use this since ages without 
problems.

> > I don't see where the problem is! I have no problem with this keys.
>
> Well, what does the time_remaining key do when one battery is 100% and
> charged, and the other is at 70% and discharging? Does it take the
> system AC value and decide on that, or does it take the individual
> battery charging action? When the AC is added, at what point do we
> remove the key and re-add it as the other state?

time_remaining? Do you mean battery.remaining_time? this is per battery 
device. Where is the problem? If the AC get added and the state of the 
battery change from discharging to charging the value should get set to some 
default (-1 or 0) and set to a correct value if the next value catched. At 
least you have IMO the same problem if you have 2 keys.

> > I don't understand what this should bring. What is the advantage? They
> > can be temporary incorrect in the same way as only one key. And one key
> > provide together with battery.rechargeable.is_(dis)charging as two keys.
> > If there are any problems with only one key and incorrect dates, we have
> > to fix them (maybe need to change the workflow and set better default
> > values if the AC/battery state change) and not to add new keys which
> > don't provide more information.
>
> Erm, the fundamental problem is we are using one key to represent two
> items of information. As the AC/BAT events happen in the bios out of
> order and with a small delay, the time_remaining key becomes in a
> quasi-state of being valid and not valid as the checks on the battery
> values is done.

Sorry, But I don't have this problem. There is maybe the problem from above to 
set the value back if the battery state change. But this is fixable and this 
does not change with a split.

> All I know is doing it this way (only setting a new key when valid) and
> removing the old key as we become non-valid removes the race condition
> in gnome-power-manager. I don't know how you do it in kpowersave, but
> I'm guessing you have some sort of delay timeout for the value to settle
> too.

Then you can set also the one key back to a default until a new get in. We 
don't use such delays in KPowersave, but we maybe handle the change workflow 
in a different way.

> Fundamentally exporting two calculated lumps of data that are calculated
> on one key is bad. It means we have to put logic in desktop programs to
> switch the value depending on another key value.

Don't understand what you mean. What logic in desktop programs? Do you ignore 
e.g. charging/discharging and AC state if you display remaining time? IMO 
this would be not the best idea. KPowersave e.g. take a look at these 3 info 
before display something. It's IMO not a good idea to depend only on one info 
in such complex and generally unreliable system as ACPI ;-)

Danny