- From: SULLIVAN, BRYAN L <bs3131@att.com>
- Date: Mon, 12 Mar 2012 15:08:23 +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>
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.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:09:47 UTC