- 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
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 first). 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. Noah [1] http://www.w3.org/TR/2009/WD-geolocation-API-20090707/ -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 --------------------------------------
Received on Friday, 21 August 2009 22:15:05 UTC