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

Re: PositionOptions.timeout & UserAgent permission

From: Andrei Popescu <andreip@google.com>
Date: Tue, 17 Mar 2009 11:18:49 +0000
Message-ID: <708552fb0903170418l15f40ff4v62e797f8ce83f8c4@mail.gmail.com>
To: Greg Bolsinga <bolsinga@apple.com>
Cc: public-geolocation <public-geolocation@w3.org>
On Tue, Mar 17, 2009 at 12:49 AM, Greg Bolsinga <bolsinga@apple.com> wrote:
>
> On Mar 16, 2009, at 5:48 AM, Andrei Popescu wrote:
>
>> Hi,
>>
>> You're right, the interaction between timeout and user permissions
>> needs to be clarified.
>>
>> We have two choices for when the timer starts:
>>
>> 1. At the moment of the call. This is what the spec says right now.
>>
>> In this case, the following would happen when the timer fires (i.e. we
>> failed to get a position fix in the given time interval):
>>
>> 1.1 The user permission was already given prior to the call. When the
>> timeout expires, the error callback is invoked with TIMEOUT.
>> 1.2 The user permission was unknown at the moment of the call... (the
>> implementation started the location acquisition process (warms up the
>> GPS / fires a request to a server / etc) and also asked the user for
>> permission.)
>>  1.2.1 The timer expires before the user has time to react. The error
>> callback is invoked with TIMEOUT.
>>  1.2.2 The user allows permission and later the timer fires. The
>> error callback is invoked with TIMEOUT.
>>  1.2.3 The user denies permission before the timer expires. The error
>> callback is invoked with PERMISSION.
>>
>> The problems I see with this scenario:
>>
>> - In case 1.2.1, what will happen to the UI once the error callback
>> has fired? If the call was a one shot request (getCurrentPosition()),
>> then the UI is now irrelevant as no matter what the user decides, the
>> call has already failed.
>> - The implementation does some work before the user permission is
>> granted. This is all useless if the permission is later denied.
>>
>> The other choice we have is:
>>
>> 2. The timer starts once the user permission is given. This can be at
>> the moment of the call if the permission was given already or later,
>> once the user interacts with a UI widget. This is Doug's
>> interpretation of the spec.
>>
>> 2.1 The user permission was already given prior to the call. When the
>> timeout expires, the error callback is invoked with TIMEOUT.
>> 2.2 The user permission was not given at the moment of the call...
>> (i.e. the implementation asked the user for permission but didn't do
>> anything else).
>> 2.2.1 If the user denies permission,  the error callback is invoked
>> with PERMISSION.
>> 2.2.2 If the user allows permission, this case is equivalent to 2.1
>>
>> The 2.* scenario doesn't have the problems with 1.*. We do need to
>> explain though that the timeout interval does not apply to the time it
>> takes for the user to grant the permission. It only applies to the
>> time it takes the implementation to acquire a location, once the
>> permission is given. However, here we also have a problem: in some
>> cases, the developer has an overall constraint on the time it takes to
>> get a position fix. This constraint is a property of the application
>> and applies no matter what causes may prevent the position to be
>> acquired (including user / UI slowness!). In this scenario, the
>> developers would be forced to use a separate window timeout, which
>> defeats the purpose of having a timeout in our own API.
>>
>> I feel that the usecase mentioned in scenario 2 is the likely usecase,
>> therefore I think it's best to stick to choice 1, given that
>> implementations can find reasonable solutions for the problems I
>> mentioned above.
>
> I'm a little confused. You seem to be equating scenario 2 and choice 1?
>

Ok, let me try to clarify: I wasn't equating scenario 2 to choice 1, I
was just saying that the usecase mentioned in scenario 2 is the likely
one.

The usecase mentioned in scenario 2:

"the developer has an overall constraint on the time it takes to get a
position fix. This constraint is a property of the application and
applies no matter what causes may prevent the position to be acquired
(including user / UI slowness!)."

choice 1:

"the timer starts at the moment of the call"


> When should the timeout start? Choice 1 doesn't make sense to me, just like
> all this timeout business.
>

What exactly doesn't make sense? Anyway, should we just remove timeout
altogether? I'd be ok with that.

>> On Sun, Mar 15, 2009 at 7:32 PM, Greg Bolsinga <bolsinga@apple.com> wrote:
>>>
>>> I'm afraid I still think that timeout, the old lastPosition, and
>>> maximumAge
>>> are still muddly. These are all implementation details. All the developer
>>> wants is a position. Developers may basically either want a precise
>>> position
>>> or a lazy position.  And when I think of developers, I do no think many
>>> are
>>> going to want the lazy position at all.
>>
>>
>> I can think of at least one set of developers who want the lazy position
>> :)
>>
>>> Why not just give them less options
>>> instead of more that they will always set to precise?
>>
>> If they only wanted the precise position, I'd be all for removing the
>> option. But given the previous point, I think we want this flexibility
>> :)
>
> But if they want to know where I used to be, I should have run the app
> sooner. Then they can cache it themselves (HTML5 offline cache anyone?). As
> you say above a window can be set via javascript outside of this API as
> well.
>

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.

Andrei
Received on Tuesday, 17 March 2009 11:19:29 UTC

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