RE: Scope and ambition of "generic sensor API"

Referring to the discussion at today's DAP on a concrete proposal for a generic/extensible sensor API I include some quick Webidl just to get a view of a possible event based structure. Still the issues in my previous mails have to be addressed as well as the scope of the API be stated. Furthermore, I am not sure if this approach in reality is more "generic" than creating a new complete event specification per sensor type we want to support. We still have to define what each new sensor type introduced is delivering.....


---+ Generic sensor Event

* The GenericSensorEvent fires on the window object.

* Registration for generic sensor events is achieved by calling window.addEventListener with event type "genericsensor".

* The initGenericSensorEvent() method must initialize the event in a manner analogous to the similarly-named method in the DOM Events interfaces. sensorType must be set to type of sensor. Could we also have input parameters for low and high thresholds?

interface SensorReading {
    readonly attribute DOMString? timestamp;
    readonly attribute float[] sensorValue;
}


interface GenericSensorEvent : Event {
    readonly attribute DomString sensorType;
    readonly attribute SensorReading reading;
    void initGenericSensorEvent(in DOMString type,
                                in boolean bubbles,
                                in boolean cancelable,
                                in DomString sensorType,
                                in SensorReading reading);
}

---+ Examples

// i) repeated

window.addEventListener('genericsensor', function (event) {
    console.log(event.sensorValue[0]);
}, true);

// ii) one-shot

function handler(event) {
    console.log(event.sensorValue[0]);
}

window.addEventListener('genericsensor', handler, true);
window.removeEventListener('genericsensor', handler, true);

attribute
sensorType of type DOMString
      The type sensor, one of

 *   "AmbientLight"
 *   "AmbientNoise"
 *   "HeartRateMonitor"
 *   "BloodGlucoseMonitor"
 *   etc

For each sensorType the meaning of the sensorValue-array must be specified.
Examples:

For "AmbientLight":
sensorType = "AmbientLight".
sensorValue[0] = the measured ambient light around the device, i.e. the illuminance, in lux.
sensorValue[1]= normalizedValue represents the measured illuminance normalized to a 0 to 1 range.
Etc...

For "HeartRateMonitor"
sensorType = "HeartRateMonitor".
sensorValue[0] = Heart rate in BPM


Regards
  Claes

From: Nilsson, Claes1
Sent: den 6 april 2011 12:47
To: 'Tran, Dzung D'; public-device-apis@w3.org
Subject: RE: Scope and ambition of "generic sensor API"

Hi,

Yes, an event model according to DeviceOrientation and Battery Status Event is an option.

Three basic questions:


1.   There are no sensitive security/privacy  concerns for device orientation and battery status but other sensors might be more sensitive. How do we address security and privacy in the event model?

2.   Can we state low and high threshold values in an event based model, e.g. by stating those in the "init event" method?

3.   An event model works well for continuous supervision of a sensor that frequently changes. However, consider the use case when you connect a sensor through USB or BT and a set of values stored in the sensor should be transferred to device to be processed by a web application. Does the model work in this case? Should we cover such a use case?

Regards
  Claes


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

Hello

I would like to start this work if everyone agree this is the scope.

Thanks
Dzung Tran

From: public-device-apis-request@w3.org<mailto:public-device-apis-request@w3.org> [mailto:public-device-apis-request@w3.org]<mailto:[mailto:public-device-apis-request@w3.org]> On Behalf Of Tran, Dzung D
Sent: Tuesday, April 05, 2011 9:30 PM
To: Nilsson, Claes1; public-device-apis@w3.org<mailto:public-device-apis@w3.org>
Subject: RE: Scope and ambition of "generic sensor API"

Claes,

As for scope, I would suggest start out with what we have in SysInfo and rewrite them to follow the event model according to DeviceOrientation. After we have this as a draft then we can discuss if further changes are needed.

Thanks
Dzung Tran


From: Nilsson, Claes1 [mailto:Claes1.Nilsson@sonyericsson.com]<mailto:[mailto:Claes1.Nilsson@sonyericsson.com]>
Sent: Tuesday, April 05, 2011 3:24 AM
To: Tran, Dzung D; public-device-apis@w3.org<mailto:public-device-apis@w3.org>
Subject: 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]<mailto:[mailto:dzung.d.tran@intel.com]>
Sent: den 4 april 2011 18:59
To: Nilsson, Claes1; public-device-apis@w3.org<mailto: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> [mailto:public-device-apis-request@w3.org]<mailto:[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<mailto: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.