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

Re: Geolocation API

From: Ryan Sarver <rsarver@skyhookwireless.com>
Date: Wed, 11 Jun 2008 13:24:33 -0400
Cc: Andrei Popescu <andreip@google.com>, "public-geolocation@w3c.org" <public-geolocation@w3c.org>
Message-Id: <C045FA59-5DA8-4ABD-AE66-B023FC737841@skyhookwireless.com>
To: Shyam Habarakada <shyamh@microsoft.com>

Sorry for taking so long to join into the discussion, but I was  
recently out of pocket a few days.

Shyam, lots of good points -- comments inline...

On Jun 7, 2008, at 6:53 PM, Shyam Habarakada wrote:

> The proposed geo location API (http://code.google.com/p/google-gears/wiki/GeolocationAPI 
> ) for web browsers correctly accounts for several key requirements.  
> Namely, the ability to query location information, the ability to  
> listen to location updated events and the ability to customize  
> location resolvers (i.e. cloud APIs that convert basic geo location  
> beacon data into richer position information). The core concepts  
> proposed are on the mark (thanks!)
> Several incremental suggestions towards better programmability and  
> standardization:
> 1.  We SHOULD convert the proposal from it's current format to a  
> standard W3C spec/draft format (sounds like Andrei is working on  
> this?).
> 2.  The new geo location object MUST be a property of the window  
> object.
> 3.  Update the name of the geo location object to GeoLocation (from  
> ‘geo’ as used in the Gears API).
>    3.1 The new name should not conflict with the current  
> window.location
>    3.2 An alternative is to expose GeoLocation as a property of the  
> navigator object.

I originally proposed it as part of the window object but a number of  
people commented that location was a property of the UA and hence  
belonged on navigator. There are clearly pros and cons to each which  
seem to weigh out, which would lead me to go with the window object as  
it is more convenient and more obvious for users.

> 4.  It MAY be better to allow two separate callbacks, one for  
> success and another for error scenarios

Definitely think its great to have some high-level disambiguation of  
the callbacks
> 5.  Once the errorCallback proposed above is implemented, we MUST  
> remove Position.errorMessage and come up with a separate  
> PositionLookupError or similar type.
>    5.1.  PositionLookupError SHOULD contain a textual errorMessage
>    5.2.  PositionLookupError MUST contain a standard numberic  
> errorCode
>    5.3.  The spec MUST enumerate possible known errorCodes for geo  
> location lookup scenarios
> 6.  PositionOptions SHOULD support the concept of a max-age when  
> returning cached Position data
> 7.  PositionOptions.gearsLocationProviderUrls is a good  
> extensibility concept.
>    7.1.  The naming here MUST be made more generic/standard as  
> opposed to the current Gears naming
>    7.2.  For the provider architecture to be truly extensibly and  
> useful as a W3C standard, interface details of the providers MUSt  
> also be documented in detail.
>    7.3.  One option is to not expose this extensibility in v1, and  
> let the user-agent hide the implementation and consider exposing  
> this once we have a better idea of how location providers can exist  
> in pluggable form.

I think its premature to have this included in the specification. I  
think the concept is interesting, but doesn't feel like it should be  
in the specification yet as there are only a *very* small number of  

> 8.  The user-agent MAY allow the user to control accuracy of  
> Position data exposed to a given authority (web-site) based on user- 
> determined trust levels. The Position data exposed through this API  
> MUST honor that user preference.

I agree that users should be able to "fuzz" their location, but when  
you return a latitude and longitude, even with an error estimate, you  
are giving a false positive of a users location. Its a complex concept  
to deal with as it would be much more useful to give a bounding box,  
or reverse geocoding information, but the data is not available to do  
it reliably. We need to come up with a way of conveying the location  
returned is not the user's actual location (IE, maybe dont put the  
marker in a map)

> 9.  Instead of the current watch method where a page can register  
> multiple listeners to get geo location update events, we SHOULD  
> consider a window.geolocation.OnChange event model. This may have  
> multiple benefits over the current proposal in controlling too many  
> listener scenarios and also aid in implementing better garbage  
> collection in the script engine.
> Thanks
> shyam habarakada
> Microsoft Corporation
Received on Thursday, 12 June 2008 14:34:57 UTC

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