- 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