- From: Andrei Popescu <andreip@google.com>
- Date: Tue, 17 Mar 2009 11:18:49 +0000
- 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