[battery] revisiting battery api using generic sensor approach (was Re: Last Call of Battery API published, LC ends 2 October 2014)

[changed subject]

The WG has devoted much time and energy progressing the current specifications, including implementer feedback. I’m not sure a restart now would be in everyone’s best interest. It seems that concluding battery as a v1 and then the WG considering whether or not to release a v.next sensor approach would make sense.

Part of the reason for this approach is that we’ve been down this monolithic sensor interface path and had reasons to not continue. I’ve started to document this on the wiki, I will update it as I have time, and other WG members may wish to add to this as well:

http://www.w3.org/2009/dap/wiki/SingleSensorSpecification

I’ll add this topic to the agenda for this week’s DAP teleconference for discussion.

regards, Frederick

Frederick Hirsch, Nokia
Chair DAP
@fjhirsch



On Sep 2, 2014, at 6:28 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:

> I'm not sure why you want to make Battery implements Sensors. It doesn't
> behave like the usual sensors. Most of the sensors are constantly
> sending value, they are updated all the time and the implementation will
> define the frequency at which it wants to get updates. Battery is fairly
> different in the sense that the system will send events when there are
> changes. For example, on Android, you get an event send for every 1%
> change. On other platforms, the events might be more often.
> 
> Because of that, I'm not sure if trying to make Battery fit the Sensors
> design is right in the first place.
> 
> -- Mounir
> 
> On Tue, 2 Sep 2014, at 05:54, Tobie Langel wrote:
>> 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
>

Received on Tuesday, 2 September 2014 19:31:32 UTC