More API breakage: battery.remaining_time

[Danny Kukawka]

On Sunday 21 January 2007 20:16, Richard Hughes wrote:
> For me, battery.remaining_time is difficult to use.

Not for me!

> It sometimes means time to discharge when on battery, but also means
> time to charge when on system AC power.

And what is the problem?

> This concept sort of breaks in the multibattery case where one battery
> can be discharging and not the other. It's also difficult to map to UPS
> values where both are possible to get.

I don't see where the problem is! I have no problem with this keys.

> More seriously, it causes races when the user unplugs AC where the
> sequence of events is very bios dependent. Sometimes the time_remaining
> value is referring to the old state for a split second when the system
> is in another case which I've had to solve for g-p-m with a 500ms
> "valid" timeout. This is pretty icky.
>
> I propose splitting battery.remaining_time into
> battery.remaining_time_until_charged and
> battery.remaining_time_until_discharged and keeping
> battery.remaining_time around for 1 year for compatibility with existing
> users. This is similar to what we are doing with suspend_to_disk.

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. 

At least I hate to change them, because this also mean other ppl and projects 
have to change code and maybe complete workflows. This isn't needed. All 
current existing projects work also well with only one key.

> Also, I really want to put a new document in HAL root called
> API-Changes.txt something like the kernel does.

Make maybe sence, but more important is it to avoid each not _really_ needed 
API change/breakage.

Danny