W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2008

Re: skeleton Geolocation API

From: Doug Turner <doug.turner@gmail.com>
Date: Fri, 20 Jun 2008 20:09:54 -0700
Cc: "Andrei Popescu" <andreip@google.com>, "public-geolocation@w3c.org" <public-geolocation@w3c.org>
Message-Id: <98A9F1F4-81F1-4EC7-BBE0-B81EE3802D37@gmail.com>
To: Ryan Sarver <rsarver@skyhookwireless.com>

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
>>
>>
>
>
>
Received on Saturday, 21 June 2008 03:10:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT