RE: Geolocation API

Follow-up on several topics from the previous thread:

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

Hmm, I didn't notice the geolocation.lastPosition property, probably because (wearing my developer hat) I was not expecting to see it there :-) My current thinking is that it would be better to simply call GetLocation with an appropriate PositionOptions.maxAge value and let the underlying implementation determine how to return the best possible result than to have the developer do something like below. Having position options control this and other parameters like timeout attributes (i.e. how long the caller is willing to wait for a Position sample) would help save the users of this API from having to worry about these details much.

/* IMO, below is an undesirable coding pattern.
 * In this pattern, the developer also needs to think about if
 * she had previously issued at least one call to get location.
 * Also note that the concept of max-age has different meaning than
 * how long the caller is willing to wait to get a valid Position
 * value, combining that into code like below would make it worse.
 */
Position p = window.geolocation.lastPosition;
if( p == undefined /* we haven't done any lookups yet */ ||
    currentTime - p.timestamp > MAX_AGE /* lastPosition was determined too long ago */)
{
    // Invoke GetLocation to get a fresh sample
}


> > 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 :)

How about PositionOptions.locationResolvers, and calling it optional?


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

Yes.

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

I have a very simple proposal here. If we define the protocol for such a service as one where it accepts geolocation beacon data (Wi-Fi hot-spot information, cell-tower ids, etc.) in a well known XML format and returns a Position either in XML or JSON, we could have that as a simple contract that user-agents could implement against. User agents may also determine if they will support none, one or multiple locationResolvers.

> >

Regarding topic #8 and #9 below, I need a bit more time to formulate a meaningful response. I'll follow up on those in the next couple of days.


shyam habarakada
Microsoft Corporation



-----Original Message-----
From: Andrei Popescu [mailto:andreip@google.com]
Sent: Monday, June 09, 2008 8:22 AM
To: Shyam Habarakada
Cc: public-geolocation@w3c.org
Subject: Re: Geolocation API

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 Thursday, 12 June 2008 19:16:06 UTC