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

RE: skeleton Geolocation API - Error codes

From: Chris Butler <cbutler@dash.net>
Date: Mon, 28 Jul 2008 11:42:36 -0700
Message-ID: <470455FBB46F8749A645E9F732A72C35029CB3B1@ex-be2.dash.net>
To: "Shyam Habarakada" <shyamh@microsoft.com>, "Alec Berntson" <alecb@windows.microsoft.com>, "Andrei Popescu" <andreip@google.com>
Cc: "Doug Turner" <doug.turner@gmail.com>, "Chris Prince" <cprince@google.com>, "Aaron Boodman" <aa@google.com>, <public-geolocation@w3c.org>

Hi Shyam.

Makes sense to me, and I really like the idea of bubbling up HTTP
errors.  

Regarding timeouts: is that something the developer can specify?  There
are probably times I am okay with a long (background processing) vs.
shorter (user action that is synchronous).

Thanks.

Chris 

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

// Modified subject to fork this discussion

Here's an updated of errorIds and descriptions to also include service
errors:

/* Errors that can occur on the user-agent/client
 */
001 AccessDenied        // User (or policy on user-agent) denied access
to geolocation
002 TimeOut             // Async operation timed out
003 NotFound            // Position could not be determined
004 NotAvailable        // Position features are not available on this
user-agent
                        // This could be the same as window.geolocation
== undefined

/* Errors that can occur when trying to use a cloud resolver service.
 * We should be able to directly buble up the HTTP response codes for
 * these 'service' related errors as indicated below.
 */
400 Service_BadRequest
401 Service_Unauthorized
402 Service_PaymentRequired
403 Service_Forbidden
404 Service_NotFound
500 Service_Failed
503 Service_TooBusy
etc.

/* A catch all error. We should decide if it is better to throw in this
scenario
 */
UnhandledException      // A catch all error for anything else


Thanks

shyam habarakada
Microsoft Corporation

-----Original Message-----
From: Alec Berntson
Sent: Monday, July 28, 2008 11:10 AM
To: Chris Butler; Andrei Popescu; Shyam Habarakada
Cc: Doug Turner; Chris Prince; Aaron Boodman; public-geolocation@w3c.org
Subject: RE: skeleton Geolocation API

Here's what I was thinking:

NotSupported (not providers)
Error           (generic)
Timeout         (call to provider took too long)
AccessDenied (user hasn't given permission to this site/app)
Running         (Location acquisition is working)

-----Original Message-----
From: Chris Butler [mailto:cbutler@dash.net]
Sent: Monday, July 28, 2008 10:10 AM
To: Andrei Popescu; Shyam Habarakada
Cc: Doug Turner; Chris Prince; Alec Berntson; Aaron Boodman;
public-geolocation@w3c.org
Subject: RE: skeleton Geolocation API

Hi everyone.

This is a little bit of a different issue and may add color to the
discussion regarding optional vs. required: what are all the possible
errors we are considering?

Would timeouts be part of it?

Thanks.

Chris
Received on Monday, 28 July 2008 18:43:19 GMT

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