- From: Andrei Popescu <andreip@google.com>
- Date: Thu, 2 Apr 2009 11:20:47 +0100
- To: Greg Bolsinga <bolsinga@apple.com>
- Cc: public-geolocation <public-geolocation@w3.org>
Hi Greg! On Wed, Apr 1, 2009 at 5:58 PM, Greg Bolsinga <bolsinga@apple.com> wrote: > First off, I'm swamped. Sorry for not responding sooner. > > On Mar 30, 2009, at 5:40 AM, Andrei Popescu wrote: > >> 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. > > Since they are both asynchronous, I see no difference personally. So I'd > vote for only the watch method. I like simplicity in APIs. ;) > I do see a difference (as explained above) so I'd vote for keeping both :) >> 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 > > Since this is an asynchronous API, how can it delay application loading? In > my implementation, where the location comes from is a separate process. > And where is that separate process getting location from? Andrei
Received on Thursday, 2 April 2009 10:21:26 UTC