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

It means that unless there is a specific reason to expose all sensors 
measuring a property, we would simplify it as just one property. For 
instance, not expose each fan in the system, but rather expose a global 
cooling activity value. Or not each CPU but rather a single CPU load.

"specific reason" was decided by the WG as meaning: "use case that does 
more than expose each sensor's value for monitoring purposes". For 
instance, there seems to be little value to expose each thermometer to 
the API, since all webapps (other than system monitors) won't really 
need to retrieve each individual temperature, but rather a single value.

So the issue is not about a single sensor API for any kind of sensor, as 
I hope is clear in my poroposal.

Max.


On 12/01/2010 14:02, Nilsson, Claes1 wrote:
> 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:56:43 UTC