skeleton Geolocation API

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 Friday, 20 June 2008 22:05:08 UTC