Re: skeleton Geolocation API

On Mon, Jun 23, 2008 at 10:28 PM, timeless <timeless@gmail.com> wrote:
> On 6/24/08, Nick Brachet <nbrachet@skyhookwireless.com> wrote:
>>  I think "enableHighAccuracy" is too limiting and wouldn't suffice to serve
>> the use-cases I highlighted.
>
> offhand i'm pretty sure i'm not a fan of enable high accuracy. perhaps
> object parameters to watch position indicating request rate and
> precision requirements.

Here is the problem that enableHighAccuracy is trying to address: In
the case where the device has, say, GPS and triangulation
capabilities, there is an accuracy/latency/battery tradeoff to
enabling GPS. Turning on GPS is more expensive in terms of battery and
latency, but (hopefully) better in terms of accuracy. For many
applications, low battery consumption, low latency, low accuracy is
preferrable. For some applications, high accuracy is required, even at
the cost of high battery consumption and latency.

How should the implementation decide whether to use GPS or not? It has
been suggested that the developer should provide a numerical desired
accuracy, but that has two problems:

1. The implementation doesn't know what accuracy GPS will be able to
provide ahead of time. So the developer providing a number doesn't do
it any good; the implementation might still have to use all available
means to find a location information source that can satisfy the
requested accuracy.

2. The developer doesn't know what number to enter. Because of the
above, the number is really getting translated into a binary choice:
use potentially expensive location information sources, or don't. But
the developer doesn't know what numbers to enter to trigger one path
or the other. A numerical desiredAccuracy field obsfucates what's
really going on inside the API, hiding an important decision the
developer needs to make (whether his application is important enough
to use high-cost location sources). I think this will just lead to
developers using Number.MIN_VALUE to represent "useHighAccuracy",
effectively translating the property into a boolean value.

It's clear, though, that this property is confusing to initial readers
of the API. I do think this is a problem. Does anyone have an idea for
clarification?

- a

Received on Tuesday, 24 June 2008 05:59:16 UTC