RE: Location quality

Hi Doug,

If I understand you properly, a lot of what you are saying is based on implementation considerations.  That shouldn't have too much of an impact on this discussion.  As far as I'm aware, the only part of this that is necessarily "synchronous" is the user authorization component.  

I wouldn't start any timer until after authorization had been granted (although this leads to an interesting time-based leak of information in that the app can use wall time to determine if authorization occurred...)

An application that is concerned about repeated access to the API (and the associated delays) could simply save the last position of its own volition.  Is it really necessary for the browser to add another cache?

That still doesn't preclude the browser from using caching to serve the response to a getCurrentPosition() request quickly; that is the crux of the point I'm making.  Caching like this doesn't need a separate hook in the API, it can just happen and based on application preferences, the cache can be used or not, as appropriate.

Cheers,
Martin

> -----Original Message-----
> From: Doug Turner [mailto:doug.turner@gmail.com]
> Sent: Friday, 24 October 2008 2:28 PM
> To: Thomson, Martin
> Cc: Andrei Popescu; public-geolocation@w3.org
> Subject: Re: Location quality
> 
> >>
> > I tend to agree that lastPosition isn't that helpful.  In fact, it's
> > totally pointless; location information is _always_ out of date.  By
> > its very nature, by the time that you've measured it, it's history.
> > But, as a matter of degree, we can usually handle a small time shift.
> >
> > The problem is that the final position that you get in your request
> > might be the product of caching somewhere along the line.  Maybe the
> > GPS is sleeping right now and it just gives you where you were 3
> > seconds ago - probably not a big deal; or maybe you got your
> > location from a network source using radio timing 2 minutes ago;
> > maybe your DSL provider told you where you were yesterday.  In some
> > cases, that cached information might be fine.  You REALLY don't want
> > to prevent caching altogether, because it's a fundamental mechanism
> > that makes location affordable.  Attempting to mandate that location
> > be measured for every request is an exercise in futility - I can
> > guarantee that you will be ignored.
> >
> > What we want to do is signal to the location provider when old
> > location isn't OK.  That's the crux of the suggestion.  Maximum age
> > signals to the provider that your three-day-old cache isn't good
> > enough.  Of course, there is always the option to ignore this - the
> > timestamp will make this evident to applications that really care.
> 
> 
> Hi Martin,
> 
> I believe that the argument for keeping lastPosition was purely for a
> javascript optimization.  You could quickly get at the last position
> that the geolocation implementation had seen without having to wait
> for the callback of watchPostion or getCurrentPosition to fire.  The
> position object, of course, will have a time attribute that the
> developer can test for.
> 
> I do agree that the method has problems.  In addition to the
> information being out of date as you suggest, the call is synchronous
> putting a significant burden on the user agent UI (modal dialog are
> bad). There was a compromise given by Aaron suggesting that we can
> return failure if the user has never previously allowed a geolocation
> request from the given URI.
> 
> I continue to see this method as, at least, not required.  I would
> like to see data that using lastPosition is significantly faster than
> using getCurrentPosition (especially in relationship to everything
> else a geolocation web application will be doing).  From a UA point of
> view, i think we should speed up the browser, not add workaround APIs
> for poor performance.
> 
> Doug Turner
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

Received on Friday, 24 October 2008 04:57:21 UTC