Re: skeleton Geolocation API

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:14:16 UTC