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

I don't think that any particular web app will need access to all. 
However, the CPU monitoring app will need access to the CPU temperatures 
(and possibly the FAN temperatures). The USB sensors would be accessed 
by the web app equivalent of the Vernier's Probeware software that is 
much used in educational environments.

While we think of web apps as toys that run on phones, we tend not to 
think of the real world issues. To me, to fulfill the promise of the 
web, we want to enable application developers to build essentially any 
app that can be conceived, and *certainly* the apps that have already 
been built.

I believe that the web has a promising future, but we mustn't dumb down 
all the APIs to such a level where apps are over constrained. The 
success of apps on the more traditional platforms is that the OS 
environments have provided a limited set of low level APIs, and these 
APIs allow apps to do anything. Linux had under 250 system calls at one 
stage. You can build any app on that set. The web has ?? (but certainly 
a lot more), and you are highly restricted in what you can do.

Yes, there are significant differences in sanbox-ability and security 
between the two platforms, but I'm not convinced that the current 
direction will lead us to the full promise of the web.

Philip

On 3/5/2012 12:02 PM, Nilsson, Claes1 wrote:
>
> I am also a ham radio operator (but not very active these days) J
>
> 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 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  <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

-- 
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