Re: General sensor API feedback

On Fri, Mar 9, 2012 at 8:29 AM, JOSE MANUEL CANTERA FONSECA <jmcf@tid.es> wrote:
>>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

What can it be useful for?

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

Yes, I think so.

>>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'?

Yes.

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

Well, depending on the outcome of the discussion regarding how often
to fire the events, we might be able to simplify things even further.

/ Jonas

Received on Thursday, 15 March 2012 21:47:13 UTC