- From: Andrei Popescu <andreip@google.com>
- Date: Tue, 29 Jul 2008 15:00:20 +0100
- 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>
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 14:01:02 UTC