- From: Greg Bolsinga <bolsinga@apple.com>
- Date: Mon, 16 Mar 2009 17:49:11 -0700
- To: Andrei Popescu <andreip@google.com>
- Cc: public-geolocation <public-geolocation@w3.org>
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