Re: PositionOptions.timeout & UserAgent permission

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.


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
:)

Thanks,
Andrei

Received on Monday, 16 March 2009 12:48:48 UTC