RE: skeleton Geolocation API - Error codes

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.

Any other thoughts?

Thanks.

Chris 

-----Original Message-----
From: Andrei Popescu [mailto:andreip@google.com] 
Sent: Wednesday, July 30, 2008 8:21 AM
To: Chris Butler
Cc: Shyam Habarakada; Alec Berntson; Doug Turner; Chris Prince; Aaron
Boodman; public-geolocation@w3c.org
Subject: Re: skeleton Geolocation API - Error codes

Hi Chris,

On Tue, Jul 29, 2008 at 5:13 PM, Chris Butler <cbutler@dash.net> wrote:
> Hi everyone.
>
> Debugging is an interesting issue, but in the case of timeouts they
> don't provide much good information.

I agree.

> To find where the timeout took
> place it requires special tools or specific knowledge of all steps of
> the process.

Right again. I also think that the users of the Geolocation API won't
really care what specific steps are involved in getting a location.

> it doesn't really matter whether it is a computer, transmission or
service issue since either way
> the user can't do some function.

Exactly.

> Also, we should assume that when we say timeout we mean from the
initial
> creation of the async request and the response being processed and
> available to the callback, right?

I assume so. One use I see for timeouts is as a developer-supplied
value, possibly on the PositionOptions interface. Such an option would
tell the Geolocation API implementation to invoke the error callback
if a valid position cannot be acquired in a given time. On the other
hand, something similar can be achieved using window.setTimeout(), so
I am not entirely sure we actually need this functionality in our
spec.

Andrei

Received on Wednesday, 30 July 2008 20:29:11 UTC