Re: skeleton Geolocation API

Hi Andrei,

Couple of clarifications/questions:

1)  Suppose there is the ability for the user to set the geolocation  
via a preference.  For instance, I have a PC in my home office -- it  
is never going to move.  If a webapp calls:

navigator.geolocation.watchPosition(scrollMap);

Is the behavior to only call |scrollMap|  "when the position changes",  
and in my example -- it would never be called, right?


2)  Are there other DOM API that use the object attributes similar to  
what we are doing in watchPosition:

{successCallback: scrollMap, errorCallback: handleError}


3) Why are there seperate calls for getCurrentPosition and  
watchPosition to simply pass an options parameter.  Can't we just make  
that optional and have a single call?


4) I am sort of confused on the names geolocation verses position.  My  
thinking was that off of the navigator object would be a "geolocator",  
and that would hand off geolocation objects.  Geolocation implies a  
position, no?


5) As discussed before, i think reverse geolocating stuff shouldn't be  
speced here.


6) enableHiqhAccuracy == implementation specific details.  Not sure it  
is that important.  What would a web author set here?  Why would they  
set it to false; and what would they expect?


7) I think many of us believe that it should be on the navigator  
object.  and hence,  ClientInformationGeolocation is just what is  
appended to navigator, right?



Regards,
Doug Turner

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 00:27:58 UTC