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

Re: skeleton Geolocation API

From: Kartikaya Gupta <lists.geolocation@stakface.com>
Date: Sat, 21 Jun 2008 03:07:27 +0000
To: Andrei Popescu <andreip@google.com>, Doug Turner <doug.turner@gmail.com>
Cc: "public-geolocation@w3c.org" <public-geolocation@w3c.org>
Message-ID: <E1K9tSN-0000Ci-0a@maggie.w3.org>

On Fri, 20 Jun 2008 17:08:54 -0700, Doug Turner <doug.turner@gmail.com> wrote:
> 5) As discussed before, i think reverse geolocating stuff shouldn't be  
> speced here.

I agree with that, but don't feel too strongly about it. If it is included though, I think there should be a way for the user to query whether or not the UA supports reverse geolocation. Right now they can set the flag but don't know whether or not they'll get back a valid address. (An error return value could be ambiguous - it might mean the UA doesn't support reverse geolocation at all, or it could mean that there was an error while reverse geolocating the current position.)

> 6) enableHiqhAccuracy == implementation specific details.  Not sure it  
> is that important.  What would a web author set here?  Why would they  
> set it to false; and what would they expect?

They might want to set it to false for the same reason that they provide "mobile" versions of their web pages - to be considerate of UAs that have fewer resources at their disposal.

> On Jun 20, 2008, at 3:04 PM, Andrei Popescu wrote:
> > 
> > * The specification should define a non-normative protocol between a
> > network location provider and the user agent.
> > Resolution: Tend to agree, to be done in the next version of the  
> > draft.
> > 

I think having the web author provide a list of network location providers is a bad idea, since it reduces the agnostic-ity of the API. (I assume here that the providers are specific to a particular input data type, such as IP address). It might also have security implications since the web author gets to dictate a server that the UA then has to ping every time a location update occurs.

Received on Saturday, 21 June 2008 03:08:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:49 UTC