Re: PositionOptions.timeout & UserAgent permission

Hi Greg,

On Thu, Mar 19, 2009 at 7:12 PM, Greg Bolsinga <bolsinga@apple.com> wrote:
> On Mar 17, 2009, at 4:18 AM, Andrei Popescu wrote:
>
>> An implementation could provide fresher cached results than a single
>> application can.
>>
>> For example, app1 runs at t1 and app2 runs at t2, where t2 > t1. When
>> you run app1 at t3, the 'lazy position' was recorded at t2, whereas
>> app1 can only remember the position at t1.
>
> This is why I think it should be an implementation detail, instead of API.
>
> If there was only the watch method, the first location returns quite
> quickly, and may be the stale location from app1, t1. The accuracy would be
> appropriately set. If this is all the client wants, they will get it.
>
> Then as the servers looking up known WiFi addresses come back with
> information, you get a more accurate callback. You use this.
>
> Then as the GPS has warmed up and you get that location, with its
> appropriate accuracy, the client uses this.
>
> In the meantime, the UI for the apps shows more and more accurate locations
> as it goes along.
>
> In addition, the client app runs its own timeout, outside of the machinery
> of Geolocation.
>

I see what you are saying and you do make a very good point. I think
there are two things here:

1. should we have only a watch method? The behavior you described is
exactly the reason why we have the 'watch' method in the API. But for
other use cases, like a camera app that needs to geotag pictures,
using getCurrentPosition() may be more convenient. I agree that you
can achieve the same effect by starting a watch and clearing it as
soon as the first callback is triggered, but it's slightly more work.
Whether it's enough to justify an extra method in the API, I am not
entirely sure. So far we thought it is.

2. the 'lazy position' feature either belongs to the API or it does
not (i.e. it is an implementation detail). Say you have an application
that has very strict latency requirements and where the location
information does not play a vital role. Such an app will want to avoid
causing any work that would increase latency (such as hitting the
network, loading the cpu, etc) during startup. The application can
provide a better user experience if the geolocation module can cheaply
return a cached position, but under no circumstances should it delay
the application loading. If the 'lazy position' is part of the API,
then you can satisfy this use case by doing a getCurrentPosition() and
specifying your maximumAge and a 0 timeout (which guarantees that no
work will be done) and, later, starting a watch. If the 'lazy
position' is not part of the API,  you cannot satisfy this use case

Thanks,
Andrei

Received on Monday, 30 March 2009 12:41:02 UTC