RE: General sensor API feedback

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