RE: Collection of bugs for sensor api - would like new WG draft with this cleanup

I am also a ham radio operator (but not very active these days) ☺

I see your point but I am not sure that I understand the use cases for when a web application would need access to all these temperature sensors.

However, I do not think that we should dig to deep into the sensor discovery method in the current sensor API draft. For general service discovery W3C is targeting Web Intents and this should apply to sensors as well. In Web Intents context it is up to the Service implementation to announce it’s service in user understandable way so that the user could make an informed decision on the specific service to use.

So most important is to start looking at use cases / scenarios for discovering and using sensors with Web Intents.

Best regards
  Claes

From: Philip Gladstone [mailto:pgladstone@cisco.com]
Sent: den 2 mars 2012 18:16
To: public-device-apis@w3.org
Subject: Re: Collection of bugs for sensor api - would like new WG draft with this cleanup

If the app doesn't know which sensor to use, I doubt that the user will know either -- especially if the sensors have names like:

Temperature-CPU1
Temperature-CPU2
Temperature-FAN4
Temperature-FAN1
Temperature-Int@248A
Temperature-I2C@1c:LM86
Temperature-USB/1/3/4/5
Temperature-USB/1/3/4/7
Temperature-USB/1/47
Temperature-1-Wire@1f0000441e4a3d0011

How on earth is a user supposed to make sense of this mess? If you think this will never happen, then look at your sound input/output options on your desktop system.

I have twelve audio input devices: USB headset, soundcard microphone input, soundcard line in front, soundcard line in back, soundcard SPDIF in, microphone in webcam, bluetooth paired headset, external usb soundcard line in, external usb soundcard spdif in, virtual audio cables 1, 2 & 3. I may be unusual in that I'm a ham radio operator, but I'm not unique.

Philip

On 3/2/2012 11:33 AM, Nilsson, Claes1 wrote:
Maybe I am misunderstanding your response but I don’t mean that the input type should not be present I just mean that the callback should not return a list of sensor objects. Instead the UA’s API implementation should implement a picker allowing the user to select the sensor to use. After the user has selected the sensor the callback is issued with only one sensor object, i.e. the object for the sensor that the user selected. This gives user control and fingerprinting without user control is not possible.

I have no strong opinion on whether “search all types” should be allowed or not.

Regards
  Claes

From: Carr, Wayne [mailto:wayne.carr@intel.com]
Sent: den 2 mars 2012 17:10
To: Nilsson, Claes1; public-device-apis@w3.org<mailto:public-device-apis@w3.org>
Subject: RE: Collection of bugs for sensor api - would like new WG draft with this cleanup

Would an app ever not have any idea at all what type of sensor it wanted to use?  E.g. show the user all sensors?   I don’t see why the input type would ever need not to be present.

From: Nilsson, Claes1 [mailto:Claes1.Nilsson@sonyericsson.com]
Sent: Friday, March 02, 2012 1:29 AM
To: Carr, Wayne; public-device-apis@w3.org<mailto:public-device-apis@w3.org>
Subject: RE: Collection of bugs for sensor api - would like new WG draft with this cleanup

Hi Wayne,

Regarding #1 I have earlier posted a comment that a proposal is 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.

However, if we switch to Web Intents for sensor discovery the findSensors () method will be dropped and the general WI framework will instead be used to discover sensors.

Regards
  Claes

From: Carr, Wayne [mailto:wayne.carr@intel.com]
Sent: den 1 mars 2012 15:08
To: public-device-apis@w3.org<mailto:public-device-apis@w3.org>
Subject: Collection of bugs for sensor api - would like new WG draft with this cleanup

Collection of bugs for sensor api.  None of these are big – they’re minor corrections or clarifications.  These should be fixed and a new draft published, to avoid having people find the same bugs.

Please publish a new WG draft with these fixed – that would aid in trial implementations.  Even if this switches to a web intent – postmessage solution, having this draft cleaned up will help, because the messages will likely carry the same information.

#1
Privacy Fingerprinting problem.  Section 4.2 SensorRequest returns a list of all available sensors.   This raises privacy issues.  Specifically, a list of sensors is like returning a list of codecs supported or a list of fonts installed.  It gives a good deal of information that could be used in fingerprinting (uniquely identifying the user/device).  No search for all sensors should be allowed.  This API should only allow a search for a specific sensor type.  Otherwise, it is too much fingerprinting information.  Request: drop the part about querying all sensors without a specific sensor type as input.

#2
Section 1 Introduction first example “session.startWatch(watchOptions);”

“session” is the wrong variable name.  It should be “sensorCnx”, not “sensor”

#3
Throughout the entire draft there is discussion of “done flag” as a Boolean “was set to false”.  Where is this “done” flag?  It seems done is only a value of “readyState” but that is defined in terms of the “done flag”.
readyState of type DOMString, readonly
Represents the status of the request. It must be set to one of the following:
·         processing. If the done flag is false.
·         done. If the done flag is true.
#4
“must return the sensor's resolution of the sensor in the sensor's unit”
Phrases with “sensor in the sensor’s unit” are repeated.  It should say “unit of measurement” to make it easier for readers to parse the phrase

#5
“getting this property must return the error of the request”  -- “getting this property” occurs in multiple places.  It’s awkward to read in sentences that have a verb immediately following it.  better to drop “getting this property” and just say something like “must return the error”

#6
In section 5.1.1 Attributes  --  the attribute descriptions are listed below in alphabetical order, rather than the order in which they appear.  That seems unnatural.  Throughout the draft, parameter descriptions are in alphabetical order rather than the order in which they appear in the object.

#7
Section 5.1.1
type of type DOMString, readonly
It must return the sensor type. See table below for a list sensor types defined by this specification
There should be a link to the table it is referring to.   This would mean to imply that the only valid types are in that table.  It would be better to explicitly state other sensor types could be added outside of this specification.

#8
Section 6.2 Sensorwatchoptions threashold
Only checking for going below a particular value isn’t good.  Better to have it be an array with low threshold, high threshold and other values can be defined for specific sensors.  Having only a low threshold is not acceptable.

#9
MUST should be capitalized “hardware and must be expressed”

#10
Section 6.4 “Once the spec progress this section will be changed to comply with the DOM4 Event interfaces”   - drop the words “once the spec progress”

#11
Section 6.4.1 Sensordataevent  “reason” is a name that doesn’t seem to reflect what it is.  This is information on whether this is onetime or a watch recurreing report.  Or the attribute could be a Boolean “watchpoint” where true only if a recurring watch.

#12
Section 7 isn’t really “requirements”. It looks more like describing formats for particular types of sensors.  It should say here how others create their own additions.  Is there a registry?  Do people use prefix’s for their own namespace?

#13
Section 6.1.1 lists for Attribute status: “disconnected” – this state is not used. Request: remove it or define its use.
1.      #14
2.      Section 6.1.2 functions endWatch, read and startWatch refer to ILLEGAL_STATE exceptions, which are not defined. this should probably be INVALID_STATE_ERR (http://www.w3.org/TR/DOM-Level-3-Core/core.html#DOMException-INVALID_STATE_ERR<http://www.w3.org/TR/DOM-Level-3-Core/core.html> )
3.
4.      #15
5.      Section 8.1 Sensor Error defines the PERMISSION_DENIED error code to be a negative -100 value even though the type is unsigned short.
6.
7.      #16
8.      Important: Section 6.1.2 [Constructor(SensorOptions options)]:
This paragraph describes the algorithm for sensor lookup at construction time of the object.
From an implementer’s perspective, this requires a DOM implementation to wrap a potentially asynchronous operation (cmp. findSensors()) into a synchronous constructor.
I think this should be rewritten to queue a sensor lookup task and always return a SensorConncetion object in state new. When the lookup task completes, state transitions should occur which are signaled through “onstatuschange” or “onerror”. In  the case of a successful lookup, the state should change to open. In the case of failure, it should transition to error. As mentioned: Both signaled through the corresponding status change handlers.
9.
10.  #17 Section 4.1.1.  It isn’t clear enough what happens if no sensors are found.  Presumably, that is not an error since no error value is defined for that.  It appears “result” is of length 0 if no matching sensor is found.  It should say that.  Or if it is an error an error should be definted.









--

Philip Gladstone

Distinguished Engineer

Product Development

pgladstone@cisco.com<mailto:pgladstone@cisco.com>

Phone: +1 978-ZEN-TOAD (+1 978 936 8623)

Google: +1 978 800 1010

Ham radio: N1DQ



--

Philip Gladstone

Distinguished Engineer

Product Development

pgladstone@cisco.com<mailto:pgladstone@cisco.com>

Phone: +1 978-ZEN-TOAD (+1 978 936 8623)

Google: +1 978 800 1010

Ham radio: N1DQ