W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2010

RE: [SysInfo] proposal for ACTION-80 - Write to list on properties to drop or simplify

From: Tran, Dzung D <dzung.d.tran@intel.com>
Date: Thu, 7 Jan 2010 09:01:17 -0800
To: Max Froumentin <maxfro@opera.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <753F67ADE6F5094C9F1DBA00D1BAA8D312D66C983B@orsmsx501.amr.corp.intel.com>
On Jan 6, 2010, Max Froumentin wrote:

> 1. Power.
>  PROPOSAL: remove list of all power sources, keep only generic power 
> information with attributes:
>   - timeRemaining
>   - level (%)
>   - isCharging: applies if this is a battery
>   - isBattery

> 2. CPU
>   PROPOSAL: remove individual CPUs, just keep CPU load (0 to 1)
>   PROPOSAL: Rename CPU to SystemLoad
I don't know what this will map to is this % CPU currently in used.

> 3. Thermal
>   There are use cases where an app might want to check if the system is 
> hot, but checking CPU basically provides the same information.
>   PROPOSAL: remove Thermal altogether.
Disagreed, you can't check the CPU to get the thermal information. Also, if you decided to remove CPU then where would this info comes from. Thermal is important to throttle the CPU frequency in the use cases that I sent out before. 

An use case that I can see, is that the system is running hot and potentially shutdown, which the web apps need to know to save data in case the system shuts down. 

> 4. Cooling
> Ditto for the use cases. It's tempting to remove it too, except if we 
> might want the webapp to control it. But perhaps not for this version. 
> And we could even add something to CPU like "attribute boolean 
> coolingOn" that could be settable.
>   PROPOSAL: remove Cooling
>   QUESTION: do we want a way for webapps to act on the system load, 
> like CPU throttling?
Agreed to remove this for now till later version.

> 5. Network
> A use-case where the list of all network interfaces is one where the 
> webapp could let the user switch interfaces if a faster one exists. Or 
> select between available wireless network. It's not strictly monitoring 
> but still low-level, so I suggest removing.
>   PROPOSAL: remove list of Connections, add signalStrength to Network 
> (when applicable) as well as type (ethernet, wifi, etc.)

>   QUESTION: keep currentUploadBandwidth / currentDownloadBandwidth? 
> Perhaps a bit too privacy-invasive?
I don't see a privacy issue here.

>   QUESTION: keep ESSID, MAC, IP, and especially roaming? And also 
> min/maxBandwidths.
I suggest remove this due to privacy issue

> 6. Ambient Light
> Ambient light is directional, so different sensors could report very 
> different values. And it could be important if we want to differentiate 
> light falling on the front of the device (where the screen is) or the 
> back. But how would a webapp differentiate them?
>   QUESTION: keep list of light sensors? If so how do we differentiate?
You can differentiate by with respect to the screen, so either front or back.

> 7. Ambient Noise, Ambient Temperature, AmbientAtmosphericPressure:
>   PROPOSAL: remove sensors, keep generic value
Agreed, remove this for now till next version - might be too much for UA vendors to implement and test for this version.

> 8. Proximity
> Proximity has the exact same issue as with ambient light: it may matter 
> which sensor is reporting.
>   QUESTION: keep list of proximity sensors? If so how do we differentiate?
All phones today have proximity sensors or at least one proximity sensor. You can differentiate the same as my comment from Ambient Light.

Dzung Tran
Intel Corp
Received on Thursday, 7 January 2010 17:01:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:41 UTC