Re: Sensors API : New draft. Includes discovery proposal

Hi,

in the spec you describe SensorDataEvent.timestamp as [relative]:

        timestamp of type double, readonly
        The time in nanosecond at which the sensor data was read. This
        value is [relative to the timestamp of the first sample that was
        acquired] for this sensor.
        
Perhaps I'm misunderstanding this, but won't it make fusion much more
difficult?  If you start watching a number of sensors and they all
return their first SensorDataEvent after different, but undefined delays
then how can you resolve how they are all temporally related?

Wouldn't it be easier/better if they all shared a common timestamp
derived from the device?  Otherwise this shifts a lot of time management
overhead back onto the developers.

roBman



On Sat, 2011-10-08 at 12:14 +0200, JOSE MANUEL CANTERA FONSECA wrote:
> Hi,
> 
> 
> A new draft of the sensor API is available at [1]. It tries to capture
> the different comments received during the last conf. Call and through
> the mailing list. @Claes a proposal to support basic discovery is on
> the draft under the SensorManager interface. 
> 
> 
> Your feedback is needed. 
> 
> 
> Thanks, all the best
> 
> 
> [1] http://dev.w3.org/2009/dap/system-info/Sensors.html
> 
> 
> 
> 
> ______________________________________________________________________
> 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 Tuesday, 11 October 2011 05:46:10 UTC