RE: Power API (Re: [sysinfo] draft ready for review)

Agreed on the point below:

> An earlier version of the draft provided only 1 because, as I then 
> claimed, 1 is at least 80% of API use-cases and 2 is for system 
> monitoring applications. What convinced me to add 2 is claims that it 
> does make sense to access data on all the CPUs on a system, or all the 
> available network interfaces, or all the proximity sensors (which could 
> be measuring different proximities). So I added 2 across the board, 
> including Power, so the specification would be homogeous and people 
> wouldn't be wondering why you can query all the CPUs but not all the 
> batteries.

-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Max Froumentin
Sent: Tuesday, January 05, 2010 09:03 AM
To: Thomas Roessler
Cc: public-device-apis@w3.org
Subject: Re: Power API (Re: [sysinfo] draft ready for review)

On 05/01/2010 17:21, Thomas Roessler wrote:
> A few observations about the Power API:
>
> - What's an unsigned int?  The WebIDL editor's draft doesn't seem to define it.

Fixed, thanks. I replaced all instances with unsigned long. Perhaps it 
should be unsigned long long, I never know which to choose...

> - Milliseconds are an awkward unit to use for an estimate that's at best accurate on a +- 10min scale.

Yes, but it's still a time measurement value, and I think that it should 
be in the same unit as other similar values, starting with Date.

> - The percentage number only makes sense if one knows both the battery capacity and power consumption of the device.  What does it buy us?

It spares the webapp developer from complex calculations that are 
system-dependent and better left to the browser implementer.

> - What's our use case for the detailed enumeration of power sources?

I don't know, and I'm happy to remove it if the WG decides. But here's 
the reason why it's there: a system information API can be viewed to 
serve 2 purposes:

1. provide information about the system's state (% battery left, CPU 
load, ambient temperature)
2. provide information about the system's devices (batteries, CPUs, 
thermometers)

An earlier version of the draft provided only 1 because, as I then 
claimed, 1 is at least 80% of API use-cases and 2 is for system 
monitoring applications. What convinced me to add 2 is claims that it 
does make sense to access data on all the CPUs on a system, or all the 
available network interfaces, or all the proximity sensors (which could 
be measuring different proximities). So I added 2 across the board, 
including Power, so the specification would be homogeous and people 
wouldn't be wondering why you can query all the CPUs but not all the 
batteries.

I'm quite happy to remove the enumeration of Power sources, if the WG 
wishes.

Max.

Received on Wednesday, 6 January 2010 03:38:32 UTC