- From: Max Froumentin <maxfro@opera.com>
- Date: Wed, 06 Jan 2010 18:02:05 +0100
- To: "public-device-apis@w3.org" <public-device-apis@w3.org>
The WG decided that: "use a "generic use case"/"apps not directly targeted at monitoring the said sensors" measurement to decide whether something is to be included in SysInfo or not" I applied that criterion to the properties in the current draft, and here are proposed changes (and questions). A figure summarising those changes is available at: http://dev.w3.org/2009/dap/system-info/properties-simplified.png 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 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. 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? 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? QUESTION: keep ESSID, MAC, IP, and especially roaming? And also min/maxBandwidths. 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? 7. Ambient Noise, Ambient Temperature, AmbientAtmosphericPressure: PROPOSAL: remove sensors, keep generic value 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? Max.
Received on Wednesday, 6 January 2010 17:02:44 UTC