W3C home > Mailing lists > Public > public-geolocation@w3.org > April 2009

Re: PositionOptions.timeout & UserAgent permission

From: Andrei Popescu <andreip@google.com>
Date: Thu, 2 Apr 2009 11:20:47 +0100
Message-ID: <708552fb0904020320k26b63abdm447ba209c8d1efd1@mail.gmail.com>
To: Greg Bolsinga <bolsinga@apple.com>
Cc: public-geolocation <public-geolocation@w3.org>
Hi Greg!

On Wed, Apr 1, 2009 at 5:58 PM, Greg Bolsinga <bolsinga@apple.com> wrote:
> First off, I'm swamped. Sorry for not responding sooner.
> On Mar 30, 2009, at 5:40 AM, Andrei Popescu wrote:
>> 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.
> Since they are both asynchronous, I see no difference personally. So I'd
> vote for only the watch method. I like simplicity in APIs. ;)

I do see a difference (as explained above) so I'd vote for keeping both :)

>> 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
> Since this is an asynchronous API, how can it delay application loading? In
> my implementation, where the location comes from is a separate process.

And where is that separate process getting location from?

Received on Thursday, 2 April 2009 10:21:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:53 UTC