- From: <noah_mendelsohn@us.ibm.com>
- Date: Mon, 24 Aug 2009 11:03:42 -0400
- To: Doug Turner <doug.turner@gmail.com>
- Cc: Becky_Gibson@notesdev.ibm.com, jferrai@us.ibm.com, "Thomson, Martin" <Martin.Thomson@andrew.com>, Patrick_Mueller@us.ibm.com, public-geolocation@w3.org
Doug Turner: > I think that the argument that I recall and agreed with was that some > of these features could be implemented in a higher-level JS library. Indeed. The questions I was raising are: * Will performance be acceptable. Note that the API provides no bound at all on the frequency of upcalls. An implementation that called 1000x per second would be conforming. I think you need to at least give implementors some guarantee on what the rates will be, or else you can't tell if you're building an application that will behave acceptably. To even find a path into a browser, activate a Javascript method, and have that (user provided) method return of the interval is too short has an overhead on constrained devices. What will happen if several applications are tracking location simultanously> * In terms of making the API useful, you're asking users who care to re-implement that timing logic in each application. It's not hard, but it's duplicate work, and needs to be debugged (timing dependent code can be tricky to test). So, I think there's some incremental value in having the API do it. Whether there's enough value to justify the additional specification complexity, implementation in user agents, disruption to existing deployments, I can't say for sure. Bottom line: I think the spec should at least say something useful about the rate of updates, with the goal of letting users understand what rates of call they need to plan for (keeping in mind that users will worry both about updates that don't happen often enough, and those that might happen too often). My intuition is that the spec would be better if the user could at least give some guidance on desired update rates through the APIs, but I can't prove conclusively that it's worth the trouble to do that. Thanks in any case for considering my comments. Noah -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- Doug Turner <doug.turner@gmail.com> 08/23/2009 10:18 PM To: "Thomson, Martin" <Martin.Thomson@andrew.com> cc: <noah_mendelsohn@us.ibm.com>, <public-geolocation@w3.org>, <Becky_Gibson@notesdev.ibm.com>, <jferrai@us.ibm.com>, <Patrick_Mueller@us.ibm.com> Subject: Re: Comment on Geolocation API Specification: maximumAge and timeout On Aug 23, 2009, at 5:15 PM, Thomson, Martin wrote: > Noah's comments are quite significant in addressing some basic > usability and interoperability considerations. Control over the > rate of notifications is important. Control over the rate of notification and/or notification based on moving x distance can easily be built in web content javascript via an interval. I believed we discussed this at some, but there isn't a tracker item for it. Nor do I find anything on the mailing list search. Could it have been at the f2f? (unfortunately, i only recall the geopriv debate). I think that the argument that I recall and agreed with was that some of these features could be implemented in a higher-level JS library. Doug Turner
Received on Monday, 24 August 2009 15:02:13 UTC