- From: Andrei Popescu <andreip@google.com>
- Date: Tue, 17 Mar 2009 18:50:28 +0000
- To: Greg Bolsinga <bolsinga@apple.com>
- Cc: public-geolocation <public-geolocation@w3.org>
Hi Greg, On Tue, Mar 17, 2009 at 1:11 AM, Greg Bolsinga <bolsinga@apple.com> wrote: > These are all implementation details, and I don't think they should be in > the spec. > > As an alternate to arguing they be removed, can timeout & maximumAge be > optional suggestions? enableHighAccuracy is already defined as a hint. Some > UAs may not have a way to determine the age of a location, for example. > Well, nothing prevents an implementation from claiming it doesn't have a cached position that is fresh enough for the specified maximumAge. The spec says "Setting the maximumAge to Infinity will force the implementation to return a cached position regardless of its age" This wasn't actually meant to say that all implementations must be capable of returning a cached position but I guess it can be interpreted that way. We should relax it to say "(...) return a cached position regardless of its age, if such a position is available." How does this sound? > Here's how you'd do remove them, have a simpler API, and still be able to > get all of the above. Drop getCurrentPosition from the API completely. You're right that this makes the API simpler. However, it does not make it simpler to use. Yes, it has fewer methods, but it now takes a bit more work to use it, since now you force all apps that need a one-shot position fix to remember to also call clearWatch(). > Have > watchPosition only. As watchPosition returns locations to your callback, you > watch the accuracy for a value you are interested in (this gets around the > hint part of enableHighAccuracy). But this use doesn't achieve the same effect as using 'enableHighAccuracy'. Perhaps we should have named this 'useExpensiveProviders' or even 'useGPS'. It's a hint to the implementation to use everything it can to get the best result. Some apps don't care about very accurate results (e.g. google.com on mobile devices) so they will let this be false, so an implementation can save resources (battery). > If you don't care, you take the first > callback and clearWatch (this is getCurrentPosition path). As said above, this makes the developer do more work. > This also allows the developer to > define accuracy with their own standards (with 100 meters, etc), as > "enableHighAccuracy" is only a hint. I think this is the same point as the one above? Or am I misunderstanding? All the best, Andrei
Received on Tuesday, 17 March 2009 18:51:05 UTC