RE: Sensors simplified (or not)

Hi Max,

Yes, it seems reasonable to use the extensibility mechanism built into SysInfo to add new sensors in addition to those in the specification.

However, don't we still need some method to discover which sensors this actual device supports? I am considering something similar to Android getSensorList, http://developer.android.com/reference/android/hardware/SensorManager.html#getSensorList(int)

Regards
  Claes



> -----Original Message-----
> From: Max Froumentin [mailto:maxfro@opera.com]
> Sent: torsdag den 11 februari 2010 17:00
> To: Nilsson, Claes1
> Cc: public-device-apis@w3.org
> Subject: Re: Sensors simplified (or not)
> 
> Hi Claes,
> 
> On 11/02/2010 16:01, Nilsson, Claes1 wrote:
> > Hi Max,
> >
> > I like this idea. It is more generic and provides possibilities for
> > extensions. Assume we need some sensor discovery method?
> 
> To me, the best way would be to use the extensibility mechanism built
> into SysInfo. The specification defines a finite number of properties
> ("CPU", short for "http://www.w3.org/2009/dap/sysinfo/CPU", "Battery",
> "AmbientNoise, etc.), among which the 5 sensor types currently in the
> specification.
> 
> If someone wishes to add an extra property not defined in the
> specification, then they use their own URIs, e.g.
> http://bondi.omtp.org/2009/05/vocabulary/bluetoothVersion,

> but without short names.
> 
> Therefore, there's no discovery. DAP currently defines 5 sensor APIs,
> which a conforming implementation must support if it has the
> corresponding sensors. Outside of that, it's not DAP's problem.
> 
> Adding a discovery mechanism on top wouldn't provide the semantics of
> discovered sensors. If my webapp discovers a list of sensors, how will
> it know which one is a sphygmomanometer?
> 
> Max.

Received on Thursday, 11 February 2010 16:26:13 UTC