W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2010

RE: Sensors simplified (or not)

From: Tran, Dzung D <dzung.d.tran@intel.com>
Date: Thu, 11 Feb 2010 09:27:29 -0800
To: "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>, 'Max Froumentin' <maxfro@opera.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <753F67ADE6F5094C9F1DBA00D1BAA8D312DA57CE39@orsmsx501.amr.corp.intel.com>
Android's getSensorList seems very reasonable and simple. I guess adding this API would not create any headache.

Thanks
Dzung Tran


-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Nilsson, Claes1
Sent: Thursday, February 11, 2010 08:23 AM
To: 'Max Froumentin'
Cc: public-device-apis@w3.org
Subject: 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 17:28:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:17 UTC