RE: Scope and ambition of "generic sensor API"

Hi Dzung,

I agree that a truly generic sensor API is difficult to achieve if we by that mean an API that requires no modifications when new sensor types are introduced. Maybe we should talk about an "extensible sensor API" instead.

One option is to just extract and improve what we have for sensors in the System Information API.

Another option is to follow the event model according to the DeviceOrientation event and the proposed BatterStatus event and define a "sensor event".

However, we need to discuss to scope and requirements on this API according to my mail below.

What does Bryan and others say?

Claes



From: Tran, Dzung D [mailto:dzung.d.tran@intel.com]
Sent: den 4 april 2011 18:59
To: Nilsson, Claes1; public-device-apis@w3.org
Subject: RE: Scope and ambition of "generic sensor API"

Claes,

I think we will have a separate specification. We had a discussion about if this is generic sensor API or something more specific. A generic sensor API would be difficult to accomplish.

As for your bullet list below, the first bullet item would be addressed. As for the other two bullet items, we will need to discuss.

I was hoping to put together the first draft taking what we have already in SysInfo, but still waiting for Bryan since this is his action. It is up to Bryan if he wants to tackle this.

Thanks
Dzung Tran,


From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Nilsson, Claes1
Sent: Monday, April 04, 2011 3:33 AM
To: public-device-apis@w3.org
Subject: Scope and ambition of "generic sensor API"

Hi Bryan and all

According to my understanding we have consensus on splitting the System Information API into a set a small discrete APIs for well-known system properties as well as creating a new "generic sensor API". Bryan has the action 359: http://www.w3.org/2009/dap/track/actions/359.

I am wondering about the scope for this sensor API. Should it just be an extraction of the sensor API, i.e. section 4.8 in System Information, into a new separate specification or should we achieve something more? I guess that some clarification on this is needed for the new charter.

Sensors can be:

*      Built in the user's current device, for example a built thermometer or barometer
*      Connected with the user's current device through a local connectivity method such as USB, Bluetooth or ANT+, for example a Bluetooth enabled body or medical sensor.
*      Located anywhere in "the cloud".

Discovery is needed. Should we define a relation between the sensor API and a discovery method or should the API agnostic to discovery and leave this as an implementation issue? For example, if the web application calls the API with the property "Heart rate monitor" then the device activates Bluetooth discovery to find  and select the actual heart rate monitor.

Furthermore, there are drawbacks with the current sensor API in System Information section 4.8, e.g. :


*         Only reading. Should we cover set/calibrate sensors and writing data to actuators?

*         Only one single value per property. Don't we need structured data, e.g. a sensor reading value and a time/date stamp?

My view is that we should try to achieve something more powerful than the current section 4.8 in System Information but I am not sure on the exact level. Which is your view on the ambition of the sensor API?

Regards
  Claes
Claes Nilsson M.Sc.E.E
Senior Technology Strategist
Technology & Research - UI/App/Web

Sony Ericsson Mobile Communications
 Phone:  +46 10 80 15178
Mobile: +46 705 56 68 78
Switchboard: +46 10 80 00000
E-Mail: mailto:claes1.nilsson@sonyericsson.com
Visiting Address; Nya Vattentornet
SE-221 88 LUND,
Sweden
Disclaimer:
The information in this e-mail is confidential and may be legally privileged. It is intended solely for the named recipient(s) and access to this e-mail by anyone else is unauthorized. The views are those of the sender and not necessarily the views of Sony Ericsson and Sony Ericsson accepts no responsibility or liability whatsoever or howsoever arising in connection with this e-mail.Any attachment(s) to this message has been checked for viruses, but please rely on your own virus checker and procedures. If you contact us by e-mail, we will store your name and address to facilitate communications. If you are not the intended recipient, please inform the sender by replying this transmission and delete the e-mail and any copies of it without disclosing it.