RE: Comment on Geolocation API Specification: maximumAge and timeout

Martin Thompson writes:

> (I note, however, that maximumAge should not be related in any way 
> to the rate of notifications, and Noah's anecdote seems to indicate 
> a bug in Safari, at least from initial impressions.)

Thank you.  I wouldn't take my limited experiments as a reliable 
indication of what iPhone/Safari is doing, but I do think that the 
intended behavior of maximumAge should in any case be documented more 
clearly.  For example, regardless of what is intended, it's not 
implausible for someone to read the spec. and say "well, if I want 
readings no older than 1000ms, maybe the phone should be checking position 
that often."  You seem to indicate that reading is not what's intended.

So to reiterate my two suggestions are:

* If you think it's a good idea, consider adding better control over the 
rate of updates.
* Either way, document more clearly the intended behavior of the APIs that 
are provided

Thank you!

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Thomson, Martin" <Martin.Thomson@andrew.com>
08/23/2009 08:15 PM
 
        To:     <noah_mendelsohn@us.ibm.com>, <public-geolocation@w3.org>
        cc:     <Becky_Gibson@notesdev.ibm.com>, <jferrai@us.ibm.com>, 
<Patrick_Mueller@us.ibm.com>
        Subject:        RE: Comment on Geolocation API Specification: 
maximumAge and timeout


Noah's comments are quite significant in addressing some basic usability 
and interoperability considerations.  Control over the rate of 
notifications is important.

(I note, however, that maximumAge should not be related in any way to the 
rate of notifications, and Noah's anecdote seems to indicate a bug in 
Safari, at least from initial impressions.)


There is an analogue you might like to consider looking at.  SIP presence 
has functions that are perhaps well beyond what you would intend to build 
into this API, including:

 - minimum, maximum and average rate specification; as well as a 
recommended default for the maximum rate
 - the ability to establish value-based triggers (i.e. tell me when the 
device moves a certain distance, enters or leaves a specified area, or 
exceeds a certain speed)


Cheers,
Martin

> -----Original Message-----
> From: public-geolocation-request@w3.org [mailto:public-geolocation-
> request@w3.org] On Behalf Of noah_mendelsohn@us.ibm.com
> Sent: Saturday, 22 August 2009 8:14 AM
> To: public-geolocation@w3.org
> Cc: Becky_Gibson@notesdev.ibm.com; jferrai@us.ibm.com;
> Patrick_Mueller@us.ibm.com
> Subject: Comment on Geolocation API Specification: maximumAge and
> timeout
> 
> 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
> --------------------------------------
> 
> 
> 
> 
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information. 
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

Received on Monday, 24 August 2009 14:51:11 UTC