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

RE: skeleton Geolocation API - Error codes

From: Shyam Habarakada <shyamh@microsoft.com>
Date: Tue, 29 Jul 2008 07:44:11 -0700
To: Andrei Popescu <andreip@google.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>
Message-ID: <F2726D43C21D084F81F9C887BE881BD1551492205D@NA-EXMSG-C105.redmond.corp.microsoft.com>

Putting service error details in the errorMessage string is an acceptable solution for the debugging requirement I outlined earlier (and more importantly, as you point out, it is better given that we previously agreed that the service itself is out of scope for this spec).

TimeOut needs to be thought out a bit more though. I can see the idea of a default 'system' timeout as well as a potential user defined TimeOut that may be specified via PositionOptions (this is not currently called out in the spec). I'll think a bit more on use-cases and get back to you.

From: Andrei Popescu [andreip@google.com]
Sent: Tuesday, July 29, 2008 7:00 AM
To: Shyam Habarakada
Cc: Alec Berntson; Chris Butler; Doug Turner; Chris Prince; Aaron Boodman; public-geolocation@w3c.org
Subject: Re: skeleton Geolocation API - Error codes


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:48:20 UTC

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