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

Re: Geolocation API

From: Andrei Popescu <andreip@google.com>
Date: Mon, 9 Jun 2008 16:21:58 +0100
Message-ID: <708552fb0806090821u6e73cec4ma994c209d2afaf90@mail.gmail.com>
To: "Shyam Habarakada" <shyamh@microsoft.com>
Cc: "public-geolocation@w3c.org" <public-geolocation@w3c.org>

Hi Shyam,

Thanks a lot for the great feedback! Please see some answers inline:

On Sat, Jun 7, 2008 at 11:53 PM, Shyam Habarakada <shyamh@microsoft.com> 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?).

Yes, I am working on it.

>
> 2.  The new geo location object MUST be a property of the window object.
>

Sounds good.

> 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

Agreed. In the example at
http://code.google.com/p/google-gears/wiki/GeolocationAPI, geo is just
the name of the user-defined variable that holds the geolocation
object. The Gears module itself is called "geolocation". In the W3C
spec, as you suggested, we would define something like
window.geolocation.

>    3.2 An alternative is to expose GeoLocation as a property of the navigator object.

That's true, although I personally feel that the navigator object is
meant to hold a collection of properties that are specific to the Web
browser itself (such as version number, installed plugins, UA string,
etc). Geolocation is somewhat orthogonal to all this. What do you
think?

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

Agreed.

> 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

Agreed.

>    5.2.  PositionLookupError MUST contain a standard numberic errorCode
>    5.3.  The spec MUST enumerate possible known errorCodes for geo location lookup scenarios

Agreed.


> 6.  PositionOptions SHOULD support the concept of a max-age when returning cached Position data
>

I see some overlap here with the "geolocation.lastPosition" property,
which explicitly returns cached data and already has a timestamp. By
querying the geolocation.lastPosition property and its associated
timestamp, one could achieve the same effect as adding max-age to
PositionOptions. I'd be grateful to know your thoughts on the
lastPosition property and whether there are some other use cases for
max-age that you had in mind.


> 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

Sure, proposals welcome :)

>    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.

Do you mean that the protocol between UA implementing the geolocation
API and the server acting as a network location provider should be
documented in detail?  If that is the case, I tend to agree. However,
it's not entirely obvious if such a protocol should be in the scope of
a W3C spec or not. That's definitely a discussion we should have very
soon as we need to decide what is the exact scope of the Geolocation
API specification.

>    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.
>

We could leave it out, but this could lead to various implementations
that would not inter-operate. As said above, we need to agree if this
is the scope or not.

> 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.
>

This is interesting, but could you please describe the idea in a bit
more detail? How would the trust levels be defined? How would the user
decide which level to choose? How would the browser translate the
trust level into something meaningful to the geolocation API?


> 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.
>

If we were to do this, then an application would only be allowed one
listener, right?. From an implementation perspective, I am not sure
this matter so much, since the watches can be just simple observers
that share the same pool of location providers (i.e. adding another
watch can be done with very little overhead). Also, I am not sure I
see how this would help with the garbage collection. Could you please
explain this in a little more detail?

Many thanks,
Andrei
Received on Monday, 9 June 2008 15:22:41 GMT

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