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

Re: skeleton Geolocation API - Error codes

From: Andrei Popescu <andreip@google.com>
Date: Tue, 29 Jul 2008 15:00:20 +0100
Message-ID: <708552fb0807290700u676cf900m2f3ca6c9493793fb@mail.gmail.com>
To: "Shyam Habarakada" <shyamh@microsoft.com>
Cc: "Alec Berntson" <alecb@windows.microsoft.com>, "Chris Butler" <cbutler@dash.net>, "Doug Turner" <doug.turner@gmail.com>, "Chris Prince" <cprince@google.com>, "Aaron Boodman" <aa@google.com>, "public-geolocation@w3c.org" <public-geolocation@w3c.org>


On Mon, Jul 28, 2008 at 10:22 PM, Shyam Habarakada <shyamh@microsoft.com> wrote:
>> Would these suffice, or do you see reasons why we would want to have
>> more detailed errors? Specifically, I'm wondering about "TimeOut" and
>> the bubbling of HTTP response codes. To me, these all mean roughly the
>> same thing: there was something wrong with the network location
>> provider.
> I think TimeOut is important - Consumers of the API can check this and present end-users with a "Try again" option or auto-retry, etc. Note that this scenario is different from say, NotFound or a generic error.

Ok, but what does TimeOut mean? Is it a TCP socket timeout? Is it some
timeout related to a GPS device? The amount of time an application is
willing to wait for a location fix seems to me like a detail that is
entirely dependent on the application itself. I doubt we can specify a
timeout behavior that is universally useful.

> Bubbling up service error codes would be a _huge_ help for debugging (imagine life as a programmer if these were hidden). I don't anticipate consumers of the API using these to determine end user experience though.

On the other hand, we agreed that the protocol between the UA and the
location server is outside the scope of this spec (at least for
version 1).  But then, I'm afraid we cannot specify HTTP error codes,
either. What if different servers have different ways to return
errors? What if some implementations won't use HTTP at all to talk to
a location server? Since the communication between the UA and the
location server is a private implementation detail of the UA, errors
that happen at this level should be debugged by the implementors, not
by the Web application developers (what could they do about them?).

Currently, we have defined PositionError as follows:

interface PositionError {
    readonly int code;
    readonly DOMString message;

Note that we have a string message, in addition to the error code. We
can have the following values for the code attribute:

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).

For error type 2, the message string can contain any implementation
specific details related to why the location acquisition failed: HTTP
error codes, GPS errors, etc.

Received on Tuesday, 29 July 2008 14:01:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:51 UTC