- From: Doug Turner <doug.turner@gmail.com>
- Date: Mon, 4 Aug 2008 11:03:10 -0700
- To: "Andrei Popescu" <andreip@google.com>
- Cc: "Chris Butler" <cbutler@dash.net>, "Shyam Habarakada" <shyamh@microsoft.com>, "Alec Berntson" <alecb@windows.microsoft.com>, "Chris Prince" <cprince@google.com>, "Aaron Boodman" <aa@google.com>, public-geolocation@w3c.org
I disagree that we need to or should expose http protocol specific error codes. Otherwise sounds fine. Doug Turner On Aug 4, 2008, at 10:51 AM, Andrei Popescu wrote: > 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 18:03:50 UTC