RE: Sensors API : New draft. Includes discovery proposal

Hi Jose,

Thanks for this new draft. Comments follow:

Section 1 Introduction:


·         In the example it should be: "sensorConnection.startWatch(watchOptions);"

Section 4 Sensor Manager:


·         A general comment is that we must agree on the scope of sensor discovery. It is stated in section 1 and 4 that a list of sensors that are available on the hosting device could be retrieved. So, is this an acceptable limitation? There are several options here:

1.       Enable in-device sensors only.

2.       Enable in-device sensors as well as locally connected, USB, BT, ANT+ etc, sensors. This would for example make it possible for web applications to access sensors in accessories and support sports and health related use cases.

3.       Enable in-device sensors, locally connected sensors and sensors in local or global networks.

                We also have to consider which level of sensor discovery that has to be built into the sensor API itself and what level of discovery that has to be relied
               upon an overlaying service discovery framework.  I don't have the answer right now. The Webinos sensor API [1] relies on the Webinos service
              discover API [2] for finding sensors that could be in-device, locally connected or within a network. However, we also discussed that a separate sensor
             discovery method might be needed to make it possible for the sensor API to stand for itself. I am not sure on the approach here.


·         In this proposal as well as in the Webinos service discovery API the discovery function issues a callback for each sensor/service found. This is a flexible approach that allows the web application to build a selection list for the user or to select a found sensor/service according to the application needs. However, this has been discussed for the service discovery API proposals and the issue of privacy has been raised. The ability for web page scripts to scan the environment is a risk to privacy, and as such this must be subject to user control. An alternative to the above would be to hand the task of presenting the list of sensors and binding to a sensor selected by the user over to the browser.  The web page script would in essence be limited to defining the search parameters and requesting the browser to ask the user to make a choice and then the user agent would issue a success callback when the user has selected the sensor.


·         I assume that an application should set an event listener of type "sensoravailable" and then call listSensors(). Do we need another function for stopping the sensor search or is it enough to use removeEventListener()? Compare with SensorConnection endWatch().

Regards
  Claes

[1] http://dev.webinos.org/specifications/draft/sensors.html
[2] http://dev.webinos.org/specifications/draft/servicediscovery.html



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 JOSE MANUEL CANTERA FONSECA
Sent: den 8 oktober 2011 12:15
To: public-device-apis@w3.org<mailto:public-device-apis@w3.org>
Subject: Sensors API : New draft. Includes discovery proposal

Hi,

A new draft of the sensor API is available at [1]. It tries to capture the different comments received during the last conf. Call and through the mailing list. @Claes a proposal to support basic discovery is on the draft under the SensorManager interface.

Your feedback is needed.

Thanks, all the best

[1] http://dev.w3.org/2009/dap/system-info/Sensors.html


________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx