Re: Last Call of Battery API published, LC ends 2 October 2014

On Mon, Sep 1, 2014 at 9:36 PM, Rick Waldron <waldron.rick@gmail.com> wrote:

>
>
>
> On Mon, Sep 1, 2014 at 3:18 PM, Tobie Langel <tobie.langel@gmail.com>
> wrote:
>
>>
>> On Mon, Sep 1, 2014 at 8:41 PM, Rick Waldron <waldron.rick@gmail.com>
>> wrote:
>>
>>>
>>> On Mon, Sep 1, 2014 at 6:21 AM, Mounir Lamouri <mounir@lamouri.fr>
>>> wrote:
>>>
>>>> On Fri, 29 Aug 2014, at 20:12, Tobie Langel wrote:
>>>> > Hi,
>>>> >
>>>> > I don't understand why this API is developed separately from other
>>>> sensor
>>>> > APIs.
>>>> >
>>>> > It would be much better for developers if all sensor APIs were
>>>> > consistent.
>>>> >
>>>> > The API difference between DeviceOrientation and Geolocation was bad
>>>> > enough. Why are we repeating such mistakes over and over again?
>>>> >
>>>> > Sorry for the late and negative feedback.
>>>>
>>>> Battery API has never been very similar to those APIs and I'm not sure
>>>> the proposed Ambient Light proposal is really mature. It's not sure it
>>>> would easily apply to Battery API too. How would you change it?
>>>>
>>>
>>>
>>>   // Create an instance that checks battery level at 1hz:
>>>   var battery = new Sensor.Battery({
>>>     frequency: 1
>>>   });
>>>
>>>   battery.onchange = ...;
>>>
>>> Or, just get the value for some kind of one-time operation:
>>>
>>>   Sensor.Battery.requestValue().then(data => ...)
>>>
>>
>> So the Battery API currently exposes more high-level data, such as
>> whether it is connected or not, time left to charge the battery, etc.[1]
>>
>>  How would those be exposed?
>>
>> Directly on the Battery instance, like so:
>>
>>     battery.charging; // true or false
>>     battery.chargingTime; // time in s
>>
>
> ^^ This makes sense.
>

I think so too. In which case it's weird to have the value getter defined
on the abstract constructor's prototype. Inheritance-wise, you might want
to have something like the following, where SingleValueSensor
(bikeshed-able) defines the value and range getters along as the onchange
event handling:

Temp|Prox|Light < SingleValueSensor < Sensor

Battery, Geoloc, and friends, would inherit directly from Sensor.


> Likewise, how do you handle events in that case? Do you only keep a
>> generic onchange event? Or do you have more fine grained events
>> (e.g. onchargingtimechange, ondischargingtimechange)? Or both?
>>
>
>> In the first case, how does the developer know which fields have changed
>> without keeping a reference to the previous state object? Etc.
>>
>
> Subclasses of Sensor should be able to have any specialized (subclass
> specific) events, right?
>

Yes. See my comments above, though.

--tobie