- From: Tran, Dzung D <dzung.d.tran@intel.com>
- Date: Sun, 4 Mar 2012 19:02:06 +0000
- To: Jonas Sicking <jonas@sicking.cc>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Here are my responses: > First of all: The Sensor object has a lot of properties that doesn't > seem useful to the page. The 'power', 'vendor', and 'name' properties > doesn't seem like the page can do much useful with. When we wrote this spec we modeled this after Android's sensor API, and these were carried over from that. We probably could remove these. > I'm also not sure what the page could do with 'minDelay' and 'resolution'. This could be useful, so that the developer would know how fast the sensor can return data. > This would leave the Sensor interface with very few properties, so I'd > suggest we merge it with the SensorConnection interface. I will look into how this could be done > As for the SensorConnection interface I also have a few question: > > What is the page expected to do with the oncalibneed event? You could > certainly inform the user, but what's the user expected to do? The > only sensor where I could think this makes sense is the magnetic > compass which at least on the iPhone can be "calibrated" by moving the > phone around. Is that the only use case or do you have others in mind? Yes, you are right here. Let the user know and then they can use one of the calibration utilities that comes with their device to calibrate the sensor. Also let the user know that the data might not be accurate. > The 'error' property should use DOMError rather than SensorError. That > way we'll also switch to using a string-based error rather than a > number based one. Good point Also I will definitely consider looking the below suggestion more closely. I might have to revamp the whole Spec. Thanks, Tran >>>>>>>>>>>>>>> We should expose the latest read sensor data as a property on the SensorConnection interface. This is very useful for for example games which have a main loop which wants to read input data every 60 seconds. If we only have event-based ways of reading the sensor data that means that every page has to remember the result of the last event and read from the remembered value, rather than being able to use the interface directly. Seems nice if we provide this functionality for them. This is input we've gotten for other input related features like gamepad and keyboard. This way we can also get rid of the SensorDataEvent since we'd just need to fire plain events. What is the purpose of separating the 'new' and 'open' statuses? Seems simpler for the page to just have a 'ready' status or some such. I'm also not sure that we need to use asynchronous callbacks to get a SensorConnection object. All data from the SensorConnection is ready asynchronously anyway so the implementation won't be required to provide data synchronously just because we return a SensorConnection right away. So here's what I propose: interface SensorManager { SensorConnection getSensor(DOMString type); // returns null if device doesn't have sensor } interface SensorConnection { readonly attribute DOMString type; readonly attribute float? range; readonly attribute DOMString status; // ready/watching/error/closed readonly attribute DOMError error; // returns non-null values when watch is enabled readonly attribute float? threashold; readonly attribute float? interval; readonly attribute any data; readonly attribute Date lastUpdate; void update(); // formerly 'read()' void startWatch(SensorWatchOptions watchOptions); void endWatch(); void close(); // Not sure if this one is needed. attribute Function? onerror; attribute Function? ondata; attribute Function? onstatuschange; };
Received on Sunday, 4 March 2012 19:02:35 UTC