- From: Andrei Popescu <andreip@google.com>
- Date: Mon, 23 Jun 2008 20:44:50 +0100
- 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 one. > 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 programming... > 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, Andrei
Received on Monday, 23 June 2008 19:45:34 UTC