- From: Andrei Popescu <andreip@google.com>
- Date: Mon, 4 Aug 2008 18:51:38 +0100
- To: "Chris Butler" <cbutler@dash.net>
- Cc: "Shyam Habarakada" <shyamh@microsoft.com>, "Alec Berntson" <alecb@windows.microsoft.com>, "Doug Turner" <doug.turner@gmail.com>, "Chris Prince" <cprince@google.com>, "Aaron Boodman" <aa@google.com>, public-geolocation@w3c.org
On Wed, Jul 30, 2008 at 9:28 PM, Chris Butler <cbutler@dash.net> wrote: > Hi Andrei. > > As you state you can use the setTimer to effectively do a timeout. To > avoid weird states you would need to be able to also store that you > already timed out somewhere and check that every time that the callback > is called. > > This would address the case that you show an error message to the user > and then you get the callback. > > I would prefer to have the timeout as an error (in the error callback) > since it is much cleaner and standardized for all developers. > I see. The timeout interval is application specific, right? So we could put it on the PositionOptions interface? So how about these set of errors: 1 - Permission error. 2 - Location acquisition error: one or more of the available location providers reported an error (e.g. GPS disabled or out of order, HTTP errors, etc). 3 - Location not found: all went well with the acquisition process, but the location could not be determined (e.g. because the location server doesn't have a mapping, etc). 4 - Timeout: occurs when the specified period (via PositionOptions) has elapsed before a location fix could be acquired. Would this be a good candidate for the first version of our spec? Andrei
Received on Monday, 4 August 2008 17:52:22 UTC