RE: Drop lastPosition from Geolocation?

I'm not sure that I like the idea of adding a "backup".  If the provider is unable to provide information that meets the constraints provided by the site, then how would a backup help?

An observation, only the permission denied error condition should prevent the inclusion of the "backup".  Timeout isn't really that special.

Cheers,
Martin

> -----Original Message-----
> From: Greg Bolsinga [mailto:bolsinga@apple.com]
> Sent: Wednesday, 19 November 2008 11:31 AM
> To: Doug Turner
> Cc: public-geolocation; Richard Barnes; Thomson, Martin
> Subject: Re: Drop lastPosition from Geolocation?
> 
> 
> On Nov 19, 2008, at 9:19 AM, Doug Turner wrote:
> 
> > I was thinking it would be something like -- the web app could say,
> > "I don't care if the location is a bit stale".  So, if a web app
> > passed 600 as the modifiedSince, that would mean that the UA could
> > return a position that is <= 10 minutes old.
> >
> >
> >> An alternative could be if the UA can't provide a position within
> >> the PositionOptions timeout parameter, it will return the last
> >> position obtained by the UA, across all pages? This would need a
> >> flag supplied to let the developer know they are getting
> >> potentially stale data. Perhaps this can be a Position field in the
> >> PositionError that is lastPosition, only set when the error code is
> >> TIMEOUT?
> >
> > That is an idea.  I am not sure I like returning a position at all
> > in most error cases.
> 
> Yeah, should it be NULL except in the timeout case?
> 
> Thinking about it more, in this scenario the user would have to wait
> for the timeout to expire to get the stale data. That is probably
> acceptable, because if the location is returned before that, they
> don't get stale data. If they set timeout=0, they will get the stale
> data, unless something else is already 'hot' and has the real position.
> 
> -- Greg
> 

------------------------------------------------------------------------------------------------
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 Wednesday, 19 November 2008 17:35:33 UTC