Re: skeleton Geolocation API

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.

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

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

Best, rs

On Jun 20, 2008, at 3:04 PM, Andrei Popescu wrote:

>
> Hello,
>
> I have updated the Geolocation API editor draft by adding a skeleton
> of the actual API:
>
> http://dev.w3.org/geo/api/spec-source.html
>
> I'd be very happy to receive some feedback on it. Here is a summary of
> the issues that have been raised so far on the geolocation mailing
> list and how I have addressed them:
>
> * The new geolocation object should be a property of the navigator  
> object.
> Resolution: It seems that most people were in favor of placing the
> geolocation object as a property of navigator so I accepted this. I
> also added a note regarding the possible relocation to the window
> object since, in practice, it could save developers time by not
> forcing them to type "navigator.geolocation".
>
>
> *  It may be better to allow two separate callbacks, one for success
> and another for error scenarios
> Resolution: Agreed, added to the draft.
>
>
> * There should be a separate Error object that should provide separate
> attributes for a numeric error code and a literal error message.
> Resolution: Agreed, added to the draft.
>
>
> * PositionOptions should support the concept of a max-age when
> returning cached Position data
> Resolution: Not included. As discussed at
> http://lists.w3.org/Archives/Public/public-geolocation/2008Jun/0061.html
> , the desired behavior can be achieved by using the lastPosition
> attribute.
>
>
> * Renaming various interfaces / methods and properties of the API
> Resolution: I considered all the names that were proposed and, on the
> whole, I think that what is now in the draft spec seems like the best
> choice. If there are any technical reasons why another name might be
> better, please do let me know.
>
>
> * Using navigator.geolocation.onchange event model, instead of the
> current callback mechanism.
> Resolution: Not included. As discussed at
> http://lists.w3.org/Archives/Public/public-geolocation/2008Jun/0034.html 
> ,
> this would limit the number of position listeners / monitors that an
> application could use. Since the current model does not have this
> limitation, I have not included this suggestion in the current draft.
>
>
> * The specification should define a non-normative protocol between a
> network location provider and the user agent.
> Resolution: Tend to agree, to be done in the next version of the  
> draft.
>
>
> * The Geolocation API should provide synchronous operation
> Resolution: Not included. Acquiring a location fix may take a
> relatively long time (e.g. warming up the GPS device, reaching the
> network location provider) so a synchronous operation would block the
> UA for the entire period, which does not seem optimal.
>
>
> * Instead of callbacks, the Geolocation API should use DOM Events.
> Resolution: Not included.  I considered this and examined how using
> DOM Events would impact the API and my conclusion is that using
> callbacks will lead to a nicer API. Here is why:
>
> - It isn't really clear how DOM Events would actually work with
> getCurrentPosition() or  watchPosition(). These methods must allow an
> application to pass a PositionOptions object that determines how the
> Position is acquired.
> - The callbacks are not a novel notification mechanism as they have
> been used by methods like setTimeout() or interfaces such as HTML5
> Database.
>
>
> Many thanks,
> Andrei
>
>

Received on Saturday, 21 June 2008 02:56:56 UTC