- From: Nilsson, Claes1 <Claes1.Nilsson@sonyericsson.com>
- Date: Thu, 17 Nov 2011 14:08:29 +0100
- To: JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>, "public-device-apis@w3.org WG" <public-device-apis@w3.org>
- Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA35D6302FC6F@seldmbx03.corpusers.net>
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. · Don't we need a timeout parameter in findSensors() to state max time for this asynchronous method to last. · 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. · 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. 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
Received on Thursday, 17 November 2011 13:09:13 UTC