[webkit-dev] Multiple location providers in Geolocation API

[Greg Bolsinga]

Hello, sorry about my delay in responding, I'm terribly busy with  
other things at the moment.

I think that the most accurate response should be returned, especially  
if it is already known. For working implementations of Geolocation in  
WebCore that I know about, this is the desired behavior, as there is  
only one provider. I think having multiple providers will be the  
exception rather than the rule, so I designed around that assumption.

For general Geolocation questions (this nearly qualifies! :) I'd  
suggest the w3.org Geolocation mailing list.

Also if you believe you have found a bug in the WebCore Geolocation  
implementation, please file a bug on bugs.webkit.org.

Thanks,
-- Greg

On Jan 22, 2009, at 9:28 AM, Steve Block wrote:

> Hi,
>
> I have a question regarding the way in which multiple sources of
> location information are handled in the Geolocation API.
>
> The Geolocation API allows the user some choice over which sources of
> location information are used in a given request (a call to
> getCurrentPosition or watchPosition) through the
> PositionOptions.enablehighAccuracy property. Typically this will
> equate to whether or not a GPS is used as a source of location
> information. Given that multiple requests can execute concurrently,
> and that different options can be supplied to each request, this
> raises the question of whether a given request should make use of
> location data obtained from a source which is enabled by a
> concurrently executing request, but not enabled by the request itself.
>
> For example, in the following snippet, should the position passed to
> oneShotSuccessCallback make use of the (likely more accurate) position
> information obtained by the concurrently executing watch, which has
> enableHighAccuracy set to true?
>
> geolocation.watchPosition(watchSuccessCallback, errorCallback,
> {enableHighAccuracy: true;});
> geolocation.getCurrentPosition(oneShotSuccessCallback, errorCallback,
> {enableHighAccuracy: false;});
>
> The obvious argument against this behaviour is that it effectively
> ignores the options passed to getCurrentPosition. However, if the
> enableHighAccuracy flag is seen simply as a means to conserve
> resources such as battery life by excluding certain sources of
> location information, using the more accurate position information for
> the one-shot request makes sense, as any power-hungry devices are
> already running due to the ongoing watch request.
>
> The current code (see below for details) does not allow this
> behaviour. My question is, is this design intentional, or should the
> code be modified to prevent this behaviour?
>
> Steve
>
>
> Code details - see WebCore/page/Geolocation and
> WebCore/platform/GeolocationService. Only a single GeolocationService
> is used, which simply reports position updates to the Geolocation
> object without specifying the source of the location data. The
> Geolocation object then forwards this to all currently executing
> requests, irrespective of the options specified for that request.
> FWIW, the Gears Geolocation information does not allow this behaviour.
> Gears maintains a mapping between requests and the location sources
> used by that request.
>
> On a related note, each time a new request is made, the PostionOptions
> for that request are passed to the GeolocationService by calling
> startUpdating(PositionOptions*). This allows the GeolocationService to
> estimate which location sources are needed (ie whether GPS is to be
> used) for all currently executing requests. However, this will always
> be an upper bound, as there's no way to remove sources from the list.
> Again, is this intentional?
>
> -- 
> Google UK Limited
> Registered Office: Belgrave House, 76 Buckingham Palace Road, London  
> SW1W 9TQ
> Registered in England Number: 3977902