RE: [Sensor API] ISSUE-121: Scope of sensor API and sensor discovery

Hi DAP,

I haven't yet seen any response to my input on the Sensor API proposal from Intel and Telefonica (http://dev.w3.org/2009/dap/system-info/Sensors.html) below. Unfortunately I am not attending TPAC this year but Anders Isberg will be the Sony Ericsson representative at the DAP meeting Thursday and Friday.

Please also comment on my proposals on the mailing list.

Best regards
  Claes

From: Nilsson, Claes1
Sent: den 25 oktober 2011 09:42
To: 'public-device-apis@w3.org'
Subject: [Sensor API] ISSUE-121: Scope of sensor API and sensor discovery

Hi,

A short summary of the issue [1] is: A sensor API must provide the ability for web applications and users to get a list of sensors of certain type(s) and allow users to select and approve access to a certain specific sensor. How does this "sensor discovery functionality" relate to a general service discovery mechanism?

I see three options:


1.       Define a specific Sensor discovery method in the Sensor API that must be used to find a select a Sensor.

2.       Define a specific Sensor discovery method in the Sensor API but also address the possibility to use a general Service Discovery API in combination with the Sensor API.

3.       Don't define a specific Sensor discovery method in the Sensor API. Instead refer to a  general Service Discovery API.
In the Webinos project I took the approach of option 3 during the work with [2] because I felt that specifying a specific sensor discovery method would almost just repeat the Webinos Service discovery API functionality. However, when driving this further into standardization I am considering if option 2 wouldn't be the best approach because:
- It will allow API implementations and Web Applications using the Sensor API stand for themselves and not be dependent on another API (Service Discovery).
- On the other hand it will as allow API implementations and Web Applications using the Sensor API to use one or more other Service Discovery API to find and bind to internal or external sensors.

So, assuming option 2 I propose the following changes to the Sensor API [3]:


*         Taking the earlier mentioned issue on privacy when allowing web page scripts to scan the environment for available sensors I propose the following sensor discovery and sensor selection method:
[NoInterfaceObject] interface SensorManager  {
         PendingOperation getSensor (
                      DOMString sensorType,
                      SensorSelectedCallback   sensorSelectedCallback ,
                      optional  Options options,
                      optional  Filter  filter);
}

The user agent displays a list of available sensors based on requested type(s) and search filter. This list of sensors is not exposed to the requesting web application.

When user has selected sensor (and accordingly approved web application access to it) the sensorSelectedCallBack is issued by the UA:

[Callback, NoInterfaceObject] interface SensorSelectedCallBack {
      void  onSelected  (Sensor  sensor);
      void onError  (SensorSelectedError error);
};

The "onSelected" callback provides a Sensor object. In [3]  the "readonly attribute DOMString? Id" should be added to the Sensor object. This is a unique identity of this specific sensor that has been selected by the user.

The error callback is issued for example if the user cancels the sensor select operation or if there is timeout.

The Options interface specifies for example the timeout value for this operation.

The Filter interface defines search criteria such as "internal/remote/location" etc.


*         Modify the interface SensorConnection to use the unique sensor identity as optional parameter in the constructor instead of name.

*         If a general service discovery method is used instead or the specific sensor discovery method or the sensor identity is delivered through some out of band method then it must be possible for applications to instantiate a new sensor object. Therefore a constructor extended attribute for the Sensor interface with the in-par sensor id must be defined.

Other comments on [3]:


*         Why is "dictionary" used in the definition of the Sensor object? Is this WebIDL correct? Could dictionary be used with attributes like this? See http://dev.w3.org/2006/webapi/WebIDL/#idl-dictionaries. Should it be:
[NoInterfaceObject] interface Sensor  {
     attribute  DOMString?  id;
     attribute  float?               resolution;
     attribute  int?                   minDelay;
     attribute  int?                   range;
     attribute  DOMString?  name;
     attribute  DOMString?  type;
     attribute  float?               power;
     attribute  DOMString?  vendor;
};

Note that I added the id attribute. Furthermore I removed readonly. Not sure about this but thinks it will be needed in order create a sensor object based on a service discovered by a general Service Discovery API.


*         I miss a statement on extensibility, that is, the ability to use custom sensor types.

What do you think?

Best regards
  Claes
[1] http://www.w3.org/2009/dap/track/issues/121

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

[3] http://dev.w3.org/2009/dap/system-info/Sensors.html#idl-def-Sensor


[cid:image001.gif@01CC993D.6C9412C0]

Claes Nilsson M.Sc.E.E
Master Engineer, Research
Technology Research - Advanced Application Lab

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.