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: Nilsson, Claes1 <Claes1.Nilsson@sonyericsson.com>
Date: Tue, 12 Jan 2010 15:29:01 +0100
To: 'Max Froumentin' <maxfro@opera.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA3208923CFBA@seldmbx03.corpusers.net>
So, for Ambient Noise, Ambient Temperature, AmbientAtmosphericPressure it means that the overall ambient noise, temperature and pressure around the device can be retrieved but not the individual values for each of the sensors. This sounds reasonable so for me your proposal is ok. 

Regards
  Claes

> -----Original Message-----
> From: Max Froumentin [mailto:maxfro@opera.com]
> Sent: tisdag den 12 januari 2010 14:56
> To: Nilsson, Claes1
> Cc: public-device-apis@w3.org
> Subject: 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 14:32:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:05 GMT