RE: Sensor API : New draft

Hi,

My replies are inline below.

Best regards
  Claes

From: JOSE MANUEL CANTERA FONSECA [mailto:jmcf@tid.es]
Sent: den 17 november 2011 15:18
To: Nilsson, Claes1; public-device-apis@w3.org WG
Subject: Re: Sensor API : New draft

Hi,

Thanks for your feedback. Comments inline.

De: "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com<mailto:Claes1.Nilsson@sonyericsson.com>>
Fecha: Thu, 17 Nov 2011 14:08:29 +0100
Para: Jose Manuel Cantera Fonseca <jmcf@tid.es<mailto:jmcf@tid.es>>, "public-device-apis@w3.org<mailto:public-device-apis@w3.org> WG" <public-device-apis@w3.org<mailto:public-device-apis@w3.org>>
Asunto: RE: Sensor API : New draft

Hi Jose and DAP,

I read the minutes from the sensor session at TPAC and understood that a Web Intents based approach was a possibility for discovering sensors. Yes, I was also thinking on this possibility when I was involved in the Web Introducer, which is based on the same basic paradigm as Web Intents. So, sensor use cases should be included in the discussions in the Web Intents task force.

Ignoring that for a while and looking at your current sensor API proposal I have the following comments:


·         The findSensors() exposes a list of found sensor objects containing metadata about the sensors. Even though the user need to approve this request I see this as a privacy risk as the list of available sensors are exposed to the web application.  My proposal was to let the user agent build the list of available sensors and let the user select the sensor to use. Then a callback is issued with the sensor object for the sensor that the user has selected and the complete list of sensors are never exposed to the requesting web application.



·         I miss a filter parameter in findSensors(). The Filter interface defines search criteria such as "internal/remote/location" etc.

>> What you are suggesting I think fits better in an intent-based scenario in which a 'Sensor Selection Intent' is raised, then the UA presents a list of available sensors and finally the user chooses the target sensor. I'm fairly open to drop the sensor discovery thing from the current proposal and let that functionality to the intents proposal DAP is already working on. I think that approach would make easier for sensors to progress and to publish it as a Working Draft sooner.
[Claes:] Yes, if we are taking the Web Intents approach sensor discovery and user selection/consent of sensor should be performed based on Web Intents. This assumes that it will be possible to create a persistent binding with the selected service, sensor service in this case. However, this requirement has already been raised in the discussions on Web Intents so I think it is a MUST for Web Intents.

A possible scenario could be that sensor services are registered, either manually by the user through a registration page, or automatically through some underlying mechanism that discovers sensors through for example Bluetooth service discovery. There is already a Web Intents action http://webintents.org/pick. Let us say that we add type="sensor/*". Then we could have "sensor/*" or "sensor/atmpressure" or whatever. A web application that needs sensor data then creates an intent action "http://webintents.org/pick" of type  "sensor/*" and could then use the Web Intents messaging channel to communicate with the sensor service.

I suggest that you for now keep the findSensors() method in the specification but add an editor's not that we are evaluating how sensor discovery and binding could be integrated with a Web Intents based solution.


·         Don't we need a timeout parameter in findSensors() to state max time for this asynchronous method to last.

>> Yes that would be part of an options parameter.

·



·         Consider a "ConfigureSensor" method that configures if events are fired at regular time intervals or when values changes as well as the rate when events are fired at regular time intervals.

>> That's is currently done at the startWatch method. You can pass different parameters that configure how monitoring is being done. If you miss other parameters, please make a concrete proposal.
[Claes:] Ok

·


·         It seems as the constructors in section 6.1.2 assumes that "name" is a unique identifier for a sensor. I don't think it is.  Two similar sensors on two different devices might have the same name but they are still not the same sensor.  I assume that a unique id has to be assigned by the UA and added to the sensor object. This unique id is used as an optional parameter in the constructor to indicate the specific sensor.

>> I can understand, you are right. I will fix that part.
[Claes:] Ok

Best regards
  Claes

From: JOSE MANUEL CANTERA FONSECA [mailto:jmcf@tid.es]<mailto:[mailto:jmcf@tid.es]>
Sent: den 16 november 2011 11:02
To: public-device-apis@w3.org<mailto:public-device-apis@w3.org> WG
Subject: Re: Sensor API : New draft

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


De: Jose Manuel Cantera Fonseca <jmcf@tid.es<mailto:jmcf@tid.es>>
Fecha: Wed, 16 Nov 2011 11:01:11 +0100
Para: "public-device-apis@w3.org<mailto:public-device-apis@w3.org> WG" <public-device-apis@w3.org<mailto:public-device-apis@w3.org>>
Asunto: Sensor API : New draft

Hi there,

At [1] you will find a new version of the Sensor API draft. As per the feedback received the following changes have been implemented:

findSensors function is now async
Accelerometer, Gyro, etc. Interfaces changed as per the Geo WG suggestions
Added prose on security / privacy
new onstatuschange event
New constructor for SensorConnection, enabling extensibility through options
Minor repharasings

Concerning the prototype described during the F2F it is going to be repurposed as a PhoneGap plugin. The plan is to contribute it to the PhoneGap community in order to gain feedback and support from the developer community. An implementation for Gecko has also started.

Thanks. Feedback is needed.

All the best



________________________________
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

________________________________
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