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

Re: skeleton Geolocation API

From: Nick Brachet <nbrachet@skyhookwireless.com>
Date: Mon, 23 Jun 2008 22:08:09 -0400
Cc: "Doug Turner" <doug.turner@gmail.com>, public-geolocation@w3c.org
Message-Id: <935148CF-EC36-4BF1-9FBC-BC82BEB73F9A@skyhookwireless.com>
To: "Andrei Popescu" <andreip@google.com>

Hi Andrei,

On Jun 23, 2008, at 3:44 PM, Andrei Popescu wrote:

>> Sorry if this has been discussed before but I wonder if there is a  
>> strong
>> need to support multiple watch? Or if it is simpler to let the  
>> (very?) few
>> applications manage the distribution of location updates internally?
> Do you have a concrete use case for this? We have a UseCases section
> in the spec and I'd like to add such a usecase if you happen to have
> one.

I actually don't [have a use-case in mind for supporting multiple  
watch]. It would certainly somewhat simplify the API to only have one  
Does anyone on the group have a use-case for this?

>> The watchPosition() interface is too limiting as it doesn't give  
>> the ability
>> to the caller to specify "intent", and therefore the implementation  
>> to
>> adjust its behavior accordingly.
>> For example, if the application only cares about changes in  
>> location greater
>> than say 1Km,
> I guess it can do this with a simple "if" ?

It certainly could... but the implementation would not know that, and  
therefore would have to assume the worst.

>> or if the application only cares to be refreshed every 10
>> minutes, the provider should take this into account to optimize its
> Again, it seems that this is something that can be done already with
> the existing API. I'm not sure we need to add complexity into the API
> to satisfy usecases that can already be implemented with a bit of
> programming...

Yes the application using the API can certainly do all of this with  
simple bits of code, but the implementation of the API cannot take  
advantage of this extra knowledge.

>> processing -- power consumption on mobile devices come to mind  
>> obviously.
> That's one idea behind the enableHighAccuracy flag. As mentioned
> already, it could do with a better name. Any ideas?

I think "enableHighAccuracy" is too limiting and wouldn't suffice to  
serve the use-cases I highlighted.

Nick Brachet (nick@skyhookwireless.com)
Received on Tuesday, 24 June 2008 02:08:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:49 UTC