Device Orientation Events draft ->was RE: Sensor API feedback: OrientationData

Just to be clear, you are now talking about changes to the DeviceOrientation Events draft in the GeoLocation WG, not the Sensor API in the DAP WG, right?  

I think we all agree that there shouldn't be competing specs for these, that it should be in the DeviceOrientation Events spec.

  Wayne

[1] http://dev.w3.org/geo/api/spec-source-orientation.html 
[2] http://dev.w3.org/2009/dap/system-info/Sensors.html 

>-----Original Message-----
>From: SULLIVAN, BRYAN L [mailto:bs3131@att.com]
>Sent: Monday, March 12, 2012 1:04 AM
>To: Doug Turner
>Cc: public-device-apis@w3.org; jmcf@tid.es
>Subject: Re: Sensor API feedback: OrientationData
>
>The issue is more than power drain due to the act of sensor monitoring by the
>device, it's also the rate of event firing and the power drain caused as the app has
>to self-integrate the flood of events, and prevent the process of handling the
>events from impacting responsiveness of the device, other apps, etc. All of which
>roll up to a perception that something is not working right, if these effects are
>perceptible to the user.
>
>Thanks,
>Bryan Sullivan
>
>On Mar 11, 2012, at 4:09 PM, "Doug Turner"
><doug.turner@gmail.com<mailto:doug.turner@gmail.com>> wrote:
>
>
>Okay... That makes perfect sense. I have shown in a couple threads that we aren't
>talking about alot of power and there is a way to turn off the gyroscope sensor
>via removing the listener. I am wondering why this isn't good enough.
>
>Thanks again!
>
>Regards,
>Doug
>
>On Mar 11, 2012 1:40 PM, "SULLIVAN, BRYAN L"
><bs3131@att.com<mailto:bs3131@att.com>> wrote:
>Because the UX impact of an inefficient API (e.g. re battery impact, processor
>load, etc) will cause users to avoid apps that use the API. Thus the intent of the
>API (to serve use cases) will not be met.
>
>Thanks,
>Bryan Sullivan
>
>On Mar 9, 2012, at 5:59 PM, "Doug Turner"
><doug.turner@gmail.com<mailto:doug.turner@gmail.com><mailto:doug.turner
>@gmail.com<mailto:doug.turner@gmail.com>>> wrote:
>
>
>Thanks for the input.  I'd like to know why you think that.
>
>On Mar 9, 2012 2:27 PM, "SULLIVAN, BRYAN L"
><bs3131@att.com<mailto:bs3131@att.com><mailto:bs3131@att.com<mailto:bs
>3131@att.com>>> wrote:
>
>I agree with Jose, these types of optimizations are necessary in the API. An API
>which does not perform some reasonable signal integration (or enable the app to
>specify the event rate /conditions) will be ineffective.
>
>
>
>
>-------- Original message --------
>Subject: Re: Sensor API feedback: OrientationData
>From: JOSE MANUEL CANTERA FONSECA
><jmcf@tid.es<mailto:jmcf@tid.es><mailto:jmcf@tid.es<mailto:jmcf@tid.es>>>
>To: Doug Turner
><doug.turner@gmail.com<mailto:doug.turner@gmail.com><mailto:doug.turner
>@gmail.com<mailto:doug.turner@gmail.com>>>,"public-device-
>apis@w3.org<mailto:public-device-apis@w3.org><mailto:public-device-
>apis@w3.org<mailto:public-device-apis@w3.org>>" <public-device-
>apis@w3.org<mailto:public-device-apis@w3.org><mailto:public-device-
>apis@w3.org<mailto:public-device-apis@w3.org>>>
>CC: Re: Sensor API feedback: OrientationData
>
>
>Hi Doug,
>
>The problem with the Device Orientation Events spec is that there is no way for
>an application to specify how often the event should be raised by the UA. For
>instance Firefox Mobile implementation raises hundreds of events per second and
>when I implemented a Compass app I had to create a wrapper to filter out events
>to avoid collapsing the browser with thousands of repaints of the Compass
>canvas. But in the end battery can be drained due to this fact.
>
>I totally agree that We should not confuse developers, and we should have only
>one mechanism but Device Orientation has flaws.
>
>Thanks best
>
>El 02/03/12 20:12, "Doug Turner"
><doug.turner@gmail.com<mailto:doug.turner@gmail.com><mailto:doug.turner
>@gmail.com<mailto:doug.turner@gmail.com>>> escribió:
>
>>Hi Jonas, Tran,
>>
>>I am concerned that there is overlap between the Sensor Api and the
>>DeviceOrientaiton Spec:
>>   http://dev.w3.org/geo/api/spec-source-orientation.html

>>
>>I worry that web developers will not know which API to use.  Tran, have
>>you looked at our draft specification?  I am wondering how we can make
>>these two efforts result in something that is consistent and pleasing
>>to developers.
>>
>>
>>
>>Answer to questions Jonas raised:
>>
>>> I'm having trouble understanding the difference between the
>>>OrientationData and AccelerationData sensors.
>>
>>They are measuring different things.  Orientation has to do with
>>rotation about an axis measured by a gyro.  Acceleration will tell you
>>change in speed measured by an accelerometer.
>>
>>> it's impossible to tell the difference between gravity and acceleration.
>>
>>True. http://en.wikipedia.org/wiki/Equivalence_principle

>>
>>> is the OrientationData sensor simply a convenience function on top of
>>>the AccelerationData sensor?
>>
>>Both tell you something about the reference.  You really want to know
>>both acceleration and orientation to fully understand what is happening
>>to the reference.  You can't always determine orientation from
>>acceleration or visa versa.
>>
>>> Could someone explain the meaning of the alpha, beta and gamma values?
>>
>>The DeviceOrientation spec goes into great detail about what these
>>values are.
>>
>>
>>
>
>
>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 Monday, 12 March 2012 15:02:59 UTC