- From: Nick Brachet <nbrachet@skyhookwireless.com>
- Date: Mon, 23 Jun 2008 22:08:09 -0400
- To: "Andrei Popescu" <andreip@google.com>
- Cc: "Doug Turner" <doug.turner@gmail.com>, public-geolocation@w3c.org
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 watch. 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