W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2012

Review of Sensor API Specification 09 April 2012

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Wed, 11 Apr 2012 13:16:22 +0100
To: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <28394E4B53734907A861500E16DFCFAB@gmail.com>
Review of Sensor API Specification  09 April 2012

On Wednesday, April 11, 2012 at 12:56 PM, Marcos Caceres wrote:

> This specification defines an API for getting access to information provided by sensors available from a hosting device.

I don't think you should say hosting device. It should be generalized (so to support remove sensors, etc.).  

> 1. Introduction
> This section is non-normative
> This specification defines an API that allows application code to obtain information given by the various sensors available on a hosting device. The information provided through this API is raw sensor data. The specification is aimed at covering well-known sensors that are commonly found in devices.

Has consensus been reached to limit this to "sensors commonly found in devices"? My use case is to plug this API to use with an Arduino (to which I can plug all sorts of sensors to). If it has, what are the devices?  

> 3. Security and Privacy Considerations
> A conforming implementation of this specification must provide a mechanism that protects the user's privacy and this mechanism should ensure that no sensitive information is made available through this API without the user's express permission.

The above is not helpful. Bake it into the API and remove the above.  

> User agents must acquire permission through a user interface, unless they have prearranged trust relationships with users.

As above. Please remove this and bake it into the API at the appropriate point.  

> 4. Sensor Manager
Move this to 4.1 (or move 4.1 up here!)  
> Navigator implements SensorManager;

Because of the above, the following sentence is redundant (WebIDL already says this… remove it please):  
> All instances of the Navigator type are defined to also implement the SensorManager interface.

Also, you don't say how to implement on navigator. You need to say:  

interface NavigatorSensorManager {  
readonly attribute SensorManager SensorManager;  
Navigator implements SensorManager;  

> 4.1 SensorManager
> This is an asynchronous API that returns without blocking the calling thread.
The above is redundant if it's already stated in the algorithms. Please remove it.  
> This interface provides interfaces to applications for making sensor requests.

Sensor request is not defined. I think the above sentence is redundant: functionality is defined by the exposed methods, not by the interface itself (which is a way to get at functionality).  
> [NoInterfaceObject]

Why is this a NoInterfaceObject?  
> interface SensorManager {
> void cancelWatchpoint (SensorRequest request);
> void connectSensor (SensorRequest request, SensorSuccessCallback onSuccess, optional callback onFailure);
> };

I think Sensors should manage themselves….

Looking further at the spec, I see that almost all the issues I raised in my previous email are still present in this version. I would appreciate if you could go over my previous feedback and just delete things that don't apply any more (it saves me doing the same review again):


Kind regards,
Received on Wednesday, 11 April 2012 12:16:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:53 UTC