Re: skeleton Geolocation API

Hi Ryan,

On Sat, Jun 21, 2008 at 3:56 AM, Ryan Sarver
<rsarver@skyhookwireless.com> wrote:
> Andrei, good work on getting the initial draft out there. Here are my
> initial thoughts...
>
> - locationResolvers - I feel strongly that this does not belong in the
> specification. I still haven't heard a good argument as to why this belongs.
> Do we see any examples of this in any other like specifications? IMO, this
> should be handled behind the scenes as the burden shouldn't on the developer
> to determine who the resolvers are. And speaking as one of the possible
> resolvers, there is a lot more that goes on behind the scenes than just
> sending an enumerated list of Radio IDs and signal strengths.
>
> - requestAddress - I also feel strongly that this does not belong in the
> specification. This seems out of band for a number of reasons. First, there
> is no standard service for doing reverse-geocoding therefore it shouldn't be
> counted on. Second, reverse-geocoding is imprecise and very US oriented. I
> understand it seems simple and something that we should provide, but the
> reality is very different and ends up seeming like a clumsy add-on.

Ok, given that these two features seem very contentious, let's leave
them out for v1 of the API.


>
> - watchPosition - what are the rules around "watchPosition"? How is a "move"
> determined? Is it any change in the user's lat/lon? For periodic updates,
> couldn't a user just do a "setInterval" and call "getCurrentPosition"?
>

I imagine the implementation would use a threshold when deciding how
much change in lat/long is enough to cause a callback invocation.
Using getCurrentPosition() with a timer would be an inferior solution
since you could never get the same  granularity of updates as you do
with watchPosition().

> - Geolocator - I agree with Doug that a Geolocator would hand off Position
> or Geolocation objects. We need to clean up the nomenclature a bit.
>

Noted.

Many thanks,
Andrei

Received on Monday, 23 June 2008 19:31:34 UTC