RE: skeleton Geolocation API - Error codes

Hi everyone.

Debugging is an interesting issue, but in the case of timeouts they
don't provide much good information.  To find where the timeout took
place it requires special tools or specific knowledge of all steps of
the process.  This would be akin to having each stage pass back how long
it took to process in the response headers as X-*.  I have seen this
used for internal tools to monitor end to end service state.

Based on my experience with async HTTP requests it doesn't really matter
whether it is a computer, transmission or service issue since either way
the user can't do some function.

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?

These are definitely options based on my past experience, but I would
love to hear other people's points of view...

Thanks.

Chris 

-----Original Message-----
From: Shyam Habarakada [mailto:shyamh@microsoft.com] 
Sent: Tuesday, July 29, 2008 7:44 AM
To: Andrei Popescu
Cc: Alec Berntson; Chris Butler; Doug Turner; Chris Prince; Aaron
Boodman; public-geolocation@w3c.org
Subject: RE: skeleton Geolocation API - Error codes

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

Hi,

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.

Thanks,
Andrei

Received on Tuesday, 29 July 2008 16:13:50 UTC