Re: PositionOptions.timeout & UserAgent permission

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?

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

>
>
> 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.

I still don't see the value providing stale data to the JS program.

Thanks,
-- Greg

Received on Tuesday, 17 March 2009 00:49:53 UTC