Re: skeleton Geolocation API - Error codes

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