RE: Battery Status Event Spec

Hi Anssi, all,

Thanks for the Editor's draft.
I like the approach here based off of the events model but wondering if
there should be an alternate way as well such as the one shot API.
The idea is specify a core interface with battery info that can be used
by event model and navigator implementations to allow for
flexibility/choice for implementations and developers.


Core Interface:

interface BatteryStatus {
    readonly attribute boolean        isBattery;
    readonly attribute boolean        isCharging;
    readonly attribute float?         level;
    readonly attribute unsigned long? timeRemaining;
}

Event-based approach:

interface BatteryStatusEvent : Event, BatteryStatus {
    void initBatteryStatusEvent (in DOMString type, in boolean bubbles,
in boolean cancelable, in boolean isBattery, in boolean isCharging, in
float? level, in unsigned long? timeRemaining);

One shot approach:

Navigator implements BatteryInfo;

interface BatteryInfo {
    readonly attribute BatteryStatus batteryStatus;
};

Regards,
Suresh

-----Original Message-----
From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of Anssi Kostiainen
Sent: Tuesday, April 05, 2011 11:23 AM
To: public-device-apis@w3.org Group WG
Subject: Re: Battery Status Event Spec

Hi,

The Editor's Draft of the Battery Status Event Specification is at:

  http://dev.w3.org/2009/dap/system-info/battery-status.html

It builds on the initial draft [1] and addresses or takes a note of the
issues identified so far [2]. All feedback is welcome.

Below I address the comments received so far (thanks!). The proposed
changes have been baked in to the Editor's Draft.

On 31.3.2011, at 17.48, ext Robin Berjon wrote:

> It is certainly true that timeRemaining is hard to calculate, and will
necessarily fluctuate as the activities you perform on your computer
change. I think that it should be optional (I don't think that all
platforms support it) but that it should be exposed if available as it
is even harder for an application to evaluate it than it is for the
system.


timeRemaining is now optional i.e. nullable.

On 31.3.2011, at 16.37, ext Robin Berjon wrote:

> Maybe the best thing would be to provide some guidelines, maybe as
SHOULDs?
> 
>   * UAs SHOULD dispatch an event when timeRemaining varies by a minute
or more.
>   * UAs SHOULD dispatch an event when isCharging or isBattery changes.
>   * UAs SHOULD dispatch an event when level varies by a 1% or more.


Added the SHOULDs.

On 31.3.2011, at 1.02, ext Tran, Dzung D wrote:

> Please proceed with your plans and check in to the same location as
SysInfo API. Also, I would like to contribute if possible

Thanks, feel free to contribute.

-Anssi

[1]
http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0122.html
[2]
http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0143.html

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Wednesday, 6 April 2011 13:47:07 UTC