Re: PositionOptions.timeout & UserAgent permission

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. ;)

> 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.

I just think that the options in the API are exposing implementation  
details, when all the API is supposed to provide is the location. How  
it does it should be left up to the UA. If the UA doesn't want to  
provide super accurate locations, it won't. This is equivalent to the  
situation where it can't. No matter what, the user's program has to be  
able to deal with both of these situations.

-- Greg

Received on Wednesday, 1 April 2009 16:59:09 UTC