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

I might not be updated as I missed the last DAP call but what does "use a "generic use case"/"apps" and " PROPOSAL: remove sensors, keep generic value"  really mean? Should we create some kind of generic ambient sensors API as a replacement for Ambient Noise, Ambient Temperature, AmbientAtmosphericPressure? How would this look like?

Regards
  Claes

> -----Original Message-----
> From: public-device-apis-request@w3.org [mailto:public-device-apis-
> request@w3.org] On Behalf Of Max Froumentin
> Sent: onsdag den 6 januari 2010 18:02
> To: public-device-apis@w3.org
> Subject: [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 Tuesday, 12 January 2010 13:03:29 UTC