RE: PositionOptions.timeout & UserAgent permission

Doug's interpretation sounds the most sensible to me - you cannot expect that gaining permission is going to take less time than the site expects for getting a result.  In either case, the site should still be given the option of using window.setTimeout() if there is an absolute requirement.  Hopefully, gaining permissions will be a one-off situation for a site and permission can be gained before any time-critical operations are necessary (i.e. at registration or login time, rather than when there is an emergency in progress).

> -----Original Message-----
> From: public-geolocation-request@w3.org [mailto:public-geolocation-
> request@w3.org] On Behalf Of Andrei Popescu
> Sent: Monday, 16 March 2009 11:48 PM
> To: Greg Bolsinga
> Cc: public-geolocation
> Subject: 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
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

Received on Monday, 16 March 2009 22:24:50 UTC