Re: skeleton Geolocation API

We could add that to watchPosition, or the application could deal with  
the filtering.

something like:
    watchPosition(callback, delta_in_meters)

Doug

On Jun 21, 2008, at 9:29 AM, Chris Butler wrote:

> Hi Nick.
>
> I agree regarding the 'intent' comment.
>
> I just sent mail touching on the timing, but the magnitude in location
> change is useful to a developer as well.  :-)
>
> Thanks.
>
> Chris
>
> -----Original Message-----
> From: public-geolocation-request@w3.org
> [mailto:public-geolocation-request@w3.org] On Behalf Of Nick Brachet
> Sent: Saturday, June 21, 2008 7:17 AM
> To: Doug Turner
> Cc: public-geolocation@w3c.org
> Subject: 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 23:20:35 UTC