- From: Andrei Popescu <andreip@google.com>
- Date: Mon, 30 Mar 2009 13:40:24 +0100
- To: Greg Bolsinga <bolsinga@apple.com>
- Cc: public-geolocation <public-geolocation@w3.org>
Hi Greg, On Thu, Mar 19, 2009 at 7:12 PM, Greg Bolsinga <bolsinga@apple.com> wrote: > On Mar 17, 2009, at 4:18 AM, Andrei Popescu wrote: > >> 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. > > This is why I think it should be an implementation detail, instead of API. > > If there was only the watch method, the first location returns quite > quickly, and may be the stale location from app1, t1. The accuracy would be > appropriately set. If this is all the client wants, they will get it. > > Then as the servers looking up known WiFi addresses come back with > information, you get a more accurate callback. You use this. > > Then as the GPS has warmed up and you get that location, with its > appropriate accuracy, the client uses this. > > In the meantime, the UI for the apps shows more and more accurate locations > as it goes along. > > In addition, the client app runs its own timeout, outside of the machinery > of Geolocation. > I see what you are saying and you do make a very good point. I think there are two things here: 1. should we have only a watch method? The behavior you described is exactly the reason why we have the 'watch' method in the API. But for other use cases, like a camera app that needs to geotag pictures, using getCurrentPosition() may be more convenient. I agree that you can achieve the same effect by starting a watch and clearing it as soon as the first callback is triggered, but it's slightly more work. Whether it's enough to justify an extra method in the API, I am not entirely sure. So far we thought it is. 2. the 'lazy position' feature either belongs to the API or it does not (i.e. it is an implementation detail). Say you have an application that has very strict latency requirements and where the location information does not play a vital role. Such an app will want to avoid causing any work that would increase latency (such as hitting the network, loading the cpu, etc) during startup. The application can provide a better user experience if the geolocation module can cheaply return a cached position, but under no circumstances should it delay the application loading. If the 'lazy position' is part of the API, then you can satisfy this use case by doing a getCurrentPosition() and specifying your maximumAge and a 0 timeout (which guarantees that no work will be done) and, later, starting a watch. If the 'lazy position' is not part of the API, you cannot satisfy this use case Thanks, Andrei
Received on Monday, 30 March 2009 12:41:02 UTC