W3C home > Mailing lists > Public > public-geolocation@w3.org > July 2008

Re: skeleton Geolocation API - Error codes

From: Andrei Popescu <andreip@google.com>
Date: Wed, 30 Jul 2008 16:21:02 +0100
Message-ID: <708552fb0807300821q1bebfcc2meb91819ef7a09036@mail.gmail.com>
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

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 15:21:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT