Re: Collection of bugs for sensor api - would like new WG draft with this cleanup from Philip Gladstone on 2012-03-02 (public-device-apis@w3.org from March 2012)

From: Philip Gladstone <pgladstone@cisco.com>
Date: Fri, 02 Mar 2012 12:16:02 -0500
To: public-device-apis@w3.org
Message-ID: <4F510052.2010407@cisco.com>
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
> *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
> *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
> *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 valueisn’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 isonetime or a 
> watch recurreing report.  Or the attribute could be a Boolean 
> “watchpoint” where true only ifa 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
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
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ
Received on Friday, 2 March 2012 17:16:44 UTC