RE: Geolocation API

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.

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

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.

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.

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 Saturday, 7 June 2008 22:56:38 UTC