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

Re: skeleton Geolocation API

From: Andrei Popescu <andreip@google.com>
Date: Mon, 23 Jun 2008 20:44:50 +0100
Message-ID: <708552fb0806231244h14eb68f2pc70b4ad77c1c978f@mail.gmail.com>
To: "Nick Brachet" <nbrachet@skyhookwireless.com>
Cc: "Doug Turner" <doug.turner@gmail.com>, public-geolocation@w3c.org

Hi Nick,

On Sat, Jun 21, 2008 at 3:16 PM, Nick Brachet
<nbrachet@skyhookwireless.com> wrote:
> Hi Doug (and everyone),
> 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

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

> 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

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

Many thanks,
Received on Monday, 23 June 2008 19:45:34 UTC

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