Re: skeleton Geolocation API

Hi Doug (and everyone),

Sorry if this has been discussed before but I wonder if there is a  
strong need to support multiple watch? Or if it is simpler to let the  
(very?) few applications manage the distribution of location updates  
internally?

The watchPosition() interface is too limiting as it doesn't give the  
ability to the caller to specify "intent", and therefore the  
implementation to adjust its behavior accordingly.
For example, if the application only cares about changes in location  
greater than say 1Km, or if the application only cares to be refreshed  
every 10 minutes, the provider should take this into account to  
optimize its processing -- power consumption on mobile devices come to  
mind obviously.

Nick.

On Jun 20, 2008, at 11:09 PM, Doug Turner wrote:

>
> fwiw, here is the idl I created for the mozilla implementation.   
> Please forgive the dialect of idl.... it is a mozilla thing.
>
> http://people.mozilla.org/~dougt/geo_idls/
>
> basically, how I would imagine it working is:
>
> nsIDOMNavigatorGeolocator would be implemented by the navigator  
> object.
>
> nsIDOMNavigatorGeolocator provides access to an attribute called  
> 'geolocator' which implements a nsIDOMGeolocator.
>
> From here, you can do something like:
>
> navigator.geolocator.
>
>
> The rest should be straight forward.  I currently only have one  
> callback method -- i didn't separate out the failure case yet.
>
> Doug Turner
>
>
> On Jun 20, 2008, at 7:56 PM, Ryan Sarver 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.
>>
>> - 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
>>>
>>>
>>
>>
>>
>
>
>
>

Nick Brachet (nick@skyhookwireless.com)

Received on Saturday, 21 June 2008 16:25:28 UTC