RE: Geolocation API

[AlecB] I am assuming that lastPosition cannot be accessed, or will be null until the user gives permission to this page, right? What if the user revokes permission after giving permissions - will lastPosition be nulled out at that point?


-----Original Message-----
From: Andrei Popescu [mailto:andreip@google.com]
Sent: Thursday, June 12, 2008 1:52 PM
To: Shyam Habarakada
Cc: public-geolocation@w3c.org; Alec Berntson
Subject: Re: Geolocation API

On Thu, Jun 12, 2008 at 8:15 PM, Shyam Habarakada <shyamh@microsoft.com> wrote:
> 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.
>

We wanted an explicit lastPosition property because it is not
ambiguous and it is easy to understand. getCurrentPosition() semantics
are also simple: you call it and you get a fresh fix. Sure, we could
add "max-age" and explain that it changes the behavior of
getCurrentPosition() so that it may return cached data or call the
error callback if the UA takes too long to acquire a fix. However, if
an application wants these features, it can simply implement them. I'm
not sure we should over-complicate the API with features that can be
very easily implemented by our users?


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

Sounds good to me.

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

I think this also fits with my thinking but I can't recall any
precedent where a W3C spec like this defines a communication protocol.
Could that be a problem? :)

Thanks,
Andrei