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

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