Re: Drop lastPosition from Geolocation?

After thinking about this a bit and discussing it with a few people, I  
think we need some way to get the "last position the UA saw".  Some  
geolocation providers, such as wifi->location require a round trip  
from the UA to the a server.  This could have a significant latency,  
and really hurt many web applications.

It is my position that we should not have synchronous API because  
building a security UI around such a system doesn't work.  This was  
the core reason I suggested dropping lastPosition.

Instead, I think we can do something different and both have a  
asynchronous API and get the last position the browser saw by adding a  
new PositionOption:


interface PositionOptions {
     ...
     attribute unsigned long modifiedSince;
   };


The modifiedSince value specified in (seconds provides a hint that the  
application would like a cached position as so long as it has been  
updated within the time specified.  If the UA does not have a cached  
position, the modifiedSince option will be ignored.


Thoughts?

Doug Turner






On Nov 17, 2008, at 4:04 PM, Richard Barnes wrote:

> +2!  (+1 each to Doug and Greg)
>
> That seems like the right approach to me, especially if the two  
> sites are in different security/privacy contexts.
>
> --Richard
>
> Greg Bolsinga wrote:
>> On Nov 17, 2008, at 2:39 PM, Doug Turner wrote:
>>>
>>> fwiw I think the point of this was so that you didn't ahve to wait  
>>> until the callback happened.... so if one web application was  
>>> using geolocaiton, another application could get a quick sync  
>>> result when it first starts up.
>> Oh, WebCore isn't currently implemented that way! :) Each page gets  
>> a fresh Geolocation implementation.
>> -- Greg