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

General sensor API feedback

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 2 Mar 2012 11:53:54 +0100
Message-ID: <CA+c2ei8pkfF-wJxsHsLiriC-pu+M8MBmNop8W0-JBjmuLxwTuA@mail.gmail.com>
To: public-device-apis@w3.org
Hi All,

I looked over the Sensor API spec and have some feedback:

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.

I'm also not sure what the page could do with 'minDelay' and 'resolution'.

This would leave the Sensor interface with very few properties, so I'd
suggest we merge it with the SensorConnection interface.


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?

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.

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 Friday, 2 March 2012 10:54:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:52 UTC