Re: General sensor API feedback

Hi Jonas,

Some comments inline

El 02/03/12 11:53, "Jonas Sicking" <jonas@sicking.cc> escribió:

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

Yes. We can get rid of them
>
>I'm also not sure what the page could do with 'minDelay' and 'resolution'.

Well minDelay and resolution can be useful to know what are the
capabilities of the sensor you are dealing with
>
>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?
Yes, that was the primary
>
>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.
ok
>
>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.

Ok, but SensorDataEvent have other fields such as accuracy, maybe it can
also be moved to a field over the Connection

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

Do you mean that the initial state of a SensorConnection object would be
'ready'?

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

So you want to get rid of the constructor, and no more than one connection
to a Sensor will be possible, right?
>
>
>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;
>};
>

>I like this refactoring


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Received on Friday, 9 March 2012 16:29:29 UTC