[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