W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2012

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

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Mon, 12 Mar 2012 15:55:11 +0000
To: "Carr, Wayne" <wayne.carr@intel.com>
CC: Doug Turner <doug.turner@gmail.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, "jmcf@tid.es" <jmcf@tid.es>
Message-ID: <3EC34408-ABE0-483A-A3D2-78DB02054458@att.com>
I think Tran or Jose would have the specific set of requirements in mind.
But if needed, we can review the deltas in the upcoming DAP meeting to be sure we have consensus on it before sending to GeoLoc.

Thanks,
Bryan Sullivan

On Mar 12, 2012, at 10:17 AM, "Carr, Wayne" <wayne.carr@intel.com> wrote:

> 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:56:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:53 UTC