Re: skeleton Geolocation API

Ryan Sarver <rsarver@skyhookwireless.com>, 2008-06-20 19:56 -0700:

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

I'd also question whether this meets the kind of criteria I think
we all may be interested in aiming for here in order to get this
work done expeditiously -- the 80/20 mark or however you want to
see it. It seems like a bit of an possible afterthought or
unnatural bolt-on to the core spec. I think the group will need to
look very carefully at whether this is something that merits being
retained -- and if it's retained at all, it should be only if it's
clear that browser implementors are likely to actually implement
support for it.

> IMO, this should be handled behind the scenes as the  burden
> shouldn't on the developer to determine who the resolvers are.  

Right. I think that ought to be one of the core design goals.
Keep to an absolute minimum the amount of manual work/housekeeping
that Web developers are expected to do to make use of the API.

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

So that seems to suggest the spec for locationResolvers might
still have a long way to go yet before actually being
implementable. And if so the group will need to consider whether
it's the best use of its time or its best interests to invest time
in doing that.

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

As someone who lives in Tokyo, where the rules around discovering
physical addresses are not particularly simple or consistent, I
also wonder about how implementable or useful a reverse geocoding
mechanism would be here.

  --Mike