Re: Battery Status API changes since the last publication

Hi Marcos,

On 16.4.2012, at 16.13, ext Marcos Caceres wrote:

> On Monday, 16 April 2012 at 13:23, Anssi Kostiainen wrote:
> 
>>>> - Added [TreatNonCallableAsNull] keywords to on* handlers.
>>> 
>>> Note that [TreatNonCallableAsNull] is still in flux in WebIDL. I strongly recommend emailing the WebIDL list about this for guidance before proceeding (might save a bit of a headache later). Event handlers may end up being defined in DOM4.
>> 
>> We want to avoid blocking on that, if at all possible. [TreatNonCallableAsNull] (or an equivalent) is required by various handlers in the HTML5 spec and others by both legacy and "new" APIs. My suggestion is we follow the lead and adapt when the dust settles, if needed, but go forward with what we have now.
>> 
>> My understanding is that in this case we can adjust the spec after entering the CR without the need to jump through too many hoops. Let's not get the process get on our way.
>> 
>> (I think the general question here is how to deal with an unstable Web IDL as a normative reference.)
> 
> Ok, but you should still email them regardless. WebIDL strongly encourages the WG to do so - if only as a (non-blocking) formality. It's important to inform the WebIDL people that people are using [TreatNonCallableAsNull]:  

I sent a message to the public-script-coord ML:

  http://lists.w3.org/Archives/Public/public-script-coord/2012AprJun/0122.html

[...]

>>> I'll note that it seems pretty extreme to have four different event registers that basically do the same thing: detecting a change in charge. Why don't you merge them into a "onchange" attribute?
>> 
>> Basically the gist of the design is we don't want to fire unneeded events. Especially on an API that is there to help save same battery.

> This seems like an unnecessary optimisation in a soup of un-optimized stuff (has anyone done the Math here to prove that there would be any battery savings?… also, how often events are fired would be controlled by the platform… and you still need to do the lookup synchronously when you query the properties on the BatteryManager… so I don't see much win here… it's getters all the way down.). Developer's ability to use the API easily should always win over such things.

The API is designed to cater to developers using it both synchronously (e.g. in game main loops) as well as asynchronously (most regular use cases), so there are some calculated trade-offs re ergonomics.

I believe developers will wrap the API and bake it into libraries for the ease of use.

-Anssi

Received on Tuesday, 17 April 2012 07:49:29 UTC