W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2008

Re: skeleton Geolocation API

From: Aaron Boodman <aa@google.com>
Date: Thu, 26 Jun 2008 15:18:14 -0700
Message-ID: <278fd46c0806261518w62c39e8fva1fb93d619caa54d@mail.gmail.com>
To: "Chris Prince" <cprince@google.com>
Cc: "Doug Turner" <doug.turner@gmail.com>, "Andrei Popescu" <andreip@google.com>, timeless@gmail.com, public-geolocation@w3c.org, "Nick Brachet" <nbrachet@skyhookwireless.com>

Exactly. lastPosition is, and already was an optimization. Application
code has always had two choices:

Easy, but slower:
window.nativator.geolocation.getPosition(function(position) {
  // use it
});

Optimization, but more work:
var lastPosition = window.navigator.geolocation.lastPosition;
if (lastPosition && notTooLongAgo(lastPosition.timestamp) &&
notTooFarAway(lastPosition.accuracy)) {
  // use it
} else { // or maybe in addition...
  window.navigator.geolocation.getPosition(function(position) {
    // use it
  });
}

As an aside, "window.navigator.geolocation" sure is a lot of typing.
Are people still sure they want that instead of the nice and snappy
"window.geolocation"?

- a

On Thu, Jun 26, 2008 at 3:13 PM, Chris Prince <cprince@google.com> wrote:
> Though maybe you could argue that's already the case, since each site
> may be the first one to use Geolocation (well, first since the user's
> data was last cleared).
>
> On Thu, Jun 26, 2008 at 3:11 PM, Chris Prince <cprince@google.com> wrote:
>> Wouldn't this mean that, effectively, sites can never simply have:
>>    // [code that uses lastPosition]
>>
>> And instead, every site would need to include:
>>    if (lastPosition) {
>>      // [code that uses lastPosition]
>>    } else {
>>      getPosition()
>>      // asynchronously call [code that uses lastPosition]
>>    }
>>
>>
>> On Thu, Jun 26, 2008 at 2:54 PM, Doug Turner <doug.turner@gmail.com> wrote:
>>>
>>> On Jun 26, 2008, at 2:48 PM, Aaron Boodman wrote:
>>>
>>>> On Thu, Jun 26, 2008 at 2:44 PM, Doug Turner <doug.turner@gmail.com>
>>>> wrote:
>>>>>
>>>>> On the lastPosition attribute, I have gotten some feedback from UX people
>>>>> that dialog a modal permission dialog for this synchronous API is not
>>>>> ideal.
>>>>> I hate to do this, but could we work through the use case for this again.
>>>>> Is it simply to avoid the cost of an asynchronous callback?
>>>>
>>>> Yes, it is to be able to show something immediately in the case where
>>>> you have an old value from a previous call to the API.
>>>>
>>>> Perhaps the implementation could just return null in the case where
>>>> permission has not been granted to that origin yet?
>>>
>>>
>>> That means it will only return an non-null position if the system has a
>>> location available, and permission has been granted (and remembered)
>>> previously?
>>>
>>>
>>>
>>
>
Received on Thursday, 26 June 2008 22:18:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT