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

Do we have a summary of what needs to change in DeviceOrientation to send to the GeoLocation WG?

I got the sensor api draft url wrong below.  It should have been:
[1] http://dev.w3.org/geo/api/spec-source-orientation.html 
[2] http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html 

>-----Original Message-----
>From: SULLIVAN, BRYAN L [mailto:bs3131@att.com]
>Sent: Monday, March 12, 2012 8:08 AM
>To: Carr, Wayne
>Cc: Doug Turner; public-device-apis@w3.org; jmcf@tid.es
>Subject: Re: Device Orientation Events draft ->was RE: Sensor API feedback:
>OrientationData
>
>Perhaps, if the current API is somehow deficient in this regard. In looking at these
>aspects in DAP, we may have gone beyond the original scope of the GeoLoc API
>design. Hopefully there is time (and support in GeoLoc) to fully develop the
>requirements so we can reach consensus on any needed changes.
>
>Thanks,
>Bryan Sullivan
>
>On Mar 12, 2012, at 10:02 AM, "Carr, Wayne" <wayne.carr@intel.com> wrote:
>
>> 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.turn
>>> er @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:b
>>> s
>>> 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.e
>>> s>>>
>>> To: Doug Turner
>>> <doug.turner@gmail.com<mailto:doug.turner@gmail.com><mailto:doug.turn
>>> er
>>> @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.turn
>>> er @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:17:31 UTC