RE: renaming enableHighAccuracy

All - Being new to this group I would like to understand the rules for how disagreement is supposed to be resolved. I think we have clear disagreement here and despite my best attempt to understand how this attribute provides value I still don't see it.

IETF works based on consensus.

IEEE works requires 3/4 approval votes.

So how are contentious issues resolved? I presume it doesn't come down to one person or one company opinion.

Can you point me to the process or rules?

Allan

-----Original Message-----
From: Andrei Popescu [mailto:andreip@google.com] 
Sent: Friday, April 03, 2009 5:02 AM
To: Allan Thomson (althomso)
Cc: Angel Machín; public-geolocation
Subject: Re: renaming enableHighAccuracy

Hi Allan,

On Fri, Apr 3, 2009 at 4:50 AM, Allan Thomson (althomso)
<althomso@cisco.com> wrote:
>
> Andrei - see my responses below within <at>   </at>
>
> If there is a group desire to keep the attribute then maybe we can define the attribute in a way that allows the device "intelligence" to switch between low|high power modes without having to have that intelligence in the application. If we did that, that might satisfy my concern.
>

I think there is group desire, that's why we have it in the API. The
question is how to best define this feature.

>
> - You are developing a gadget application that lives on the desktop of
> a mobile device. This means it is most likely running all the time.
> Your app is showing POI in the user's vicinity / offers search results
> relevant to the user's location / shows where the user's friends are /
> etc. Since the application is long running (it's on the desktop),
> would you say it is reasonable for a developer to set lowPower to
> true?
>
> <at> At what point does the developer of the application switch to lowPower? An application has no way of knowing how much longer the application will run.
>

No, but you can make some reasonable assumptions. In my above example,
you are developing a desktop gadget or are maintaining a very popular
website where location is a secondary feature (e.g. on a news portal,
location is used to show weather in your current area). You look at
the API and see this 'lowPowerOnly' attribute. What would you set that
attribute to, if anything?

> So presumably the application will determine that after X time of running that it should revert to lower power.

I don't think that switching useLowPower between true and false after
X amount of time is the primary use case for this attribute. If you
really insist in having a use case where you would switch between
these states, then you could think of  would use lowPower all the
time, except when the user is asking for driving directions (so that
you get the start/end of the route accurately).

>  However, when reverting to that lower power the location accuracy will potentially change from good accuracy to less than good accuracy and the user has no way of understanding why it changed.

Right, but this is *even more* reason to have this in the API, is it
not? These changes in accuracy happen *all the time* no matter what
positioning technology you happen to be using. At least, with this
attribute present, the application can have some level of control over
the power usage and expect the accuracy to drop once it sets this
flag. This gives it a chance to show some UI that will help the user
understand why the accuracy changed.

> The application would presumably have to provide a means for the user to switch back to higher power again.

With this attribute it has a chance to do that. Without it, it cannot.

>
> - You are developing some app that offers turn-by-turn directions.
> That is a user-driven action that clearly requires accurate position
> fixes, so would you say it is reasonable to use the default values of
> the API?
>
> <at> Agreed. But what happens if the user stops in the middle of the route and has a coffee for 1 hour. Does the application keep running at high power? My point is that without intelligence to know when to stop running in high power vs low power the application would just keep running as is.
>

Sure, but what happens if you don't have this attribute and the user
stops in the middle of the route and has coffee for 1 hour? The point
of this second example was to demonstrate that we are not making the
API any worse by having this attribute. The value of the attribute
comes from solving the cases similar to the first example.

> One solution to this could be if the device has a motion sensor attached then it could determine that the device is not moving so stop location determination until it detects movement again. That way the device intelligently decides what is good for location and what is good for power consumption on the device. No need for an application to tell it.
>

Well, a concept of system idleness would probably solve it better.
While the user is having coffee, the system will probably sleep, which
will power off the location providers as well. But that really varies
from system to system and it's out of our control. The app could even
tell that the user has stopped by observing that no UI events have
happened for a while and correlate that with the fact that the
location hasn't changed either.

> Also what happens when the user enters a building and WLAN location can be provided much more easily than say GPS location (which doesn't work inside as well)? Does the application now know that low power isn't needed cause the location is now being provided by a lower powered option?

I don't understand: why would the application need to do anything in
this case? It'll just work regardless of the value of lowPower
attribute. Again, the point of this attribute is not to second guess
what the environment is and what the implementation is doing. The
point of the attribute is to express the application's power
constraints.

> Any the underlying drivers on the device can determine that change and automatically switch whereas the application would have to have that logic built into it.

Not at all. The case you describe will work without the application
having to do anything.

>
> In general, if you don't care about this issue or you want the best
> results you can get, you can just use the API with its defaults
> values. For those cases where you think the usage of this API may be
> detrimental to the user experience (e.g. by draining a phone's battery
> and preventing the user from making phone calls), I feel that this
> attribute may be useful.
>
> <at> My point is that the attribute can't be set by applications that don't understand all of the parameters that affect power consumption of location. Applications don't have that visibility but you are asking them to set this parameter. That is my objection.
> </at>

Well for those applications that don't understand how to use it or
don't care, the API should work with its default settings. I think the
current design satisfies that. This is not a reason to prevent those
applications that do know how to use it from using it. So I don't
think this objection is valid.

>
> Finally, let's have a look at what other Location APIs do:
>
> IPhone:
> http://developer.apple.com/iPhone/library/documentation/CoreLocation/Reference/CLLocationManager_Class/CLLocationManager/CLLocationManager.html#//apple_ref/occ/instm/CLLocationManager/startUpdatingLocation
>
> That method takes a desiredAccuracy attribute: "The desired accuracy
> of the location data. (...) You should assign a value to this property
> that is appropriate for your usage scenario. In other words, if you
> need only the current location within a few kilometers, you should not
> specify kCLLocationAccuracyBest for the accuracy. Determining a
> location with greater accuracy requires more time and more power".
> Note the word "power" at the end.
>
> <at> The statement on greater accuracy requires more time and more power is just misleading for certain location determination techniques. For GPS or Assisted GPS this might be true but it's not true of other techniques like WLAN location determination. If the application actually knew a WLAN technique was available then they could still get good accuracy without consuming a lot of power.
> </at>

Yes, exactly. This is exactly why I am proposing to change our
attribute from 'enableHighAccuracy' to 'lowPowerOnly'. The application
expresses its desire about power consumption and the implementation
decides how to satisfy that.

>
> <snip>
>
> (FYI, also have a look at
> http://wiki.forum.nokia.com/index.php/KIJ000875_-_GPS_Satellite_fix_results_in_reduced_battery_life
> to see the impact of GPS on a modern device)
>
> <at> And that is why GPS is not necessarily the right location determination technique in all environments.
> </at>

Right, but you'll have to admit there are a lot more outdoors use
cases than for any other environment. For outdoors, GPS is appropriate
but should be used with care for the reasons explained by Nokia in the
above article. That's why we are discussing this attribute.

>
> I understand extremely well that we're designing a much higher-level
> API than any of the above, but I think having a simple boolean
> attribute offers quite a bit of value with very little cost. But ok,
> if the majority of the people disagree, we'll take it out. But before
> that, can you please summarize the main reasons why you don't want
> this in the API (perhaps other than "devices will get better in XYZ
> years") ?
>
> <at> My primary objection is that applications will not necessarily know when to set the attribute to one value or another.

As I said, I don't agree with this objection. If this attribute
provides value for a subset of the applications that will be using
this API, then it is good to have it.

>  And if they do set the attribute, they don't have the intelligence to change the value if the RF environment changes dynamically.

But this attribute is not meant to be changed when the RF environment
changes. Applications don't need to know anything about the
environment or the location providers that are being used.
Applications simply express a desire based on factors such as the ones
in the examples I have given at the beginning (also note that
google.com uses it today on Android phones and those developers found
it useful).

> Hence optimal performance of a location application is not achieved because when the application sets the attribute to low power the user experience may not get the best location possible for the deployment environment.

But if best accuracy is important to the application, it can just use
the API with its default settings.

I'm sorry but I don't see sufficient evidence so far to remove this attribute.

Thanks,
Andrei

Received on Friday, 3 April 2009 14:50:40 UTC