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

[Sensors] feedback request: should we continue with Sensors API draft?

From: Tran, Dzung D <dzung.d.tran@intel.com>
Date: Mon, 13 Feb 2012 22:00:19 +0000
To: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <84BCA539DD96614691177EDA3CE4FF05375717B0@ORSMSX101.amr.corp.intel.com>
Hello everyone,

I was wondering if the WG still interested in continue with the Sensors API draft.

Thanks
Tran

From: Carr, Wayne [mailto:wayne.carr@intel.com]
Sent: Monday, February 13, 2012 11:22 AM
To: public-device-apis@w3.org
Subject: comments on sensor API draft (2nd set) - resent due to format problem

Passing on comments from others on sensor API draft 10 November 2011 version, http://dev.w3.org/2009/dap/system-info/Sensors.html


 1. Section 6.1.1 lists for Attribute status: “disconnected” – this state is not used. I suggest to remove it or define its use.
1.       2. Section 6.1.2 functions endWatch, read and startWatch refer to ILLEGAL_STATE exceptions, which are not defined. In my opinion, 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> )
2.
3.       3. Section 8.1 Sensor Error defines the PERMISSION_DENIED error code to be a negative -100 value even though the type is unsigned short.
4.
5.       4. 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.
6.
7.       5. In the implementation it has been useful to add a return code NO_SENSOR_FOUND = 101 to section 8.1 in cases where a lookup didn’t come back with any sensor result but no unforeseen error occurred.



Received on Monday, 13 February 2012 22:00:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:28 GMT