W3C home > Mailing lists > Public > public-geolocation@w3.org > August 2009

Comment on Geolocation API Specification: maximumAge and timeout

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 21 Aug 2009 18:14:19 -0400
To: public-geolocation@w3.org
Cc: Becky_Gibson@notesdev.ibm.com, jferrai@us.ibm.com, Patrick_Mueller@us.ibm.com
Message-ID: <OFB6EFA9B4.EC8BF26C-ON85257619.006CD755-85257619.007A2932@lotus.com>
I have some comments on the 7 July  2009 version of the Geolocation API 
Specification [1], relating in particluar to maximumAge and to timeout. To 
some extent, I'm just concerned that the explanations provided aren't as 
clear as they should be, but I'm also missing some capabilities that I 
think could be important.

Let me start with the use case I have in mind, which is to bound 
unnecessary processing overhead.  As far as I can tell, there's no way to 
say: "I'd like updates about every N milliseconds;  more than that and 
you'll be calling me too often, and less than that is too slow."  Another 
important variation might be:  "update me when I have moved by more than X 
since the last update (but no more than every M milliseconds)".

Why is this an issue?  Consider a device like the iPhone and Safari 
browser.  Invoked through watchPosition without any timeout or maximum, 
Safari seems to provide updates every second or two, whether the device 
has been moved or not, and regardless of whether the application is 
interested in such frequent updates.  What's worse, this update rate is 
not documented or predictable from the geolocation spec.  If I hadn't 
written a test application to find out, I wouldn't have a clue whether to 
expect an update every 10 seconds, or multiple updates per second. 
Furthermore, I have no assurance of even approximate compatibility across 
devices and browsers.

To some extent, applications need to be designed with update rates in 
mind.  This is especially true on a small device, as frequent updates take 
cycles away from other processing by the application, and may lead to 
individual applications implementing ad hoc logic for timing and ignoring 
updates that arrive too frequently.  By contrast, desktop Firefox called 
with the same parameters gives one (or sometimes two) updates, and then no 
more, at least on a machine that's not moving, and that may or may not be 
what's wanted in all cases either.

Also, at least on iPhone Safari, setting a maximumAge and/or a timeout 
affects the rate of updates in ways that aren't obvious, and I'm presuming 
that it's compatible with the spec.  On my iPhone, setting a maximum age 
of 10 seconds causes updates to stop entirely, and I can't prove from the 
spec. whether that's a bug.  So, a couple of specific requests:

* The exact requirements for compatible implementatin of maximumAge and 
timeout should be spelled out much more clearly.  Any possible 
interactions between the two parameters should be explained:  are there 
combinations of values that are disallowed or nonsensical?  What is the 
responsibility of the browser for any possible combination?

* Please consider providing some way for the application to specify the 
maximum rate or maybe the preferred rate at which updates are desired 
and/or other conditions (movement of more than a certain amount) that 
should trigger updates.   If multiple options are offered, please try to 
make their behavior in combination sensible for likely scenarios (update 
me every 5 seconds or when I move more than 300 feet, whichever happens 

BTW: these are my personal comments.  They do not necessarily represent 
IBM's opinion, and they are not offered in the context of my participation 
in the W3C TAG.  Thank you.


[1]  http://www.w3.org/TR/2009/WD-geolocation-API-20090707/

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Friday, 21 August 2009 22:15:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:56 UTC