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

Re: Geolocation API

From: Jon Ferraiolo <jferrai@us.ibm.com>
Date: Fri, 13 Jun 2008 09:14:39 -0700
To: Doug Turner <doug.turner@gmail.com>
Cc: Alec Berntson <alecb@windows.microsoft.com>, "public-geolocation@w3c.org" <public-geolocation@w3c.org>, public-geolocation-request@w3.org
Message-ID: <OF686EC0CF.4E41E5D6-ON88257467.0058A0FB-88257467.00593BA0@us.ibm.com>

If subscriber parameters are really necessary, I would add another optional
parameter to addEventListener() instead of inventing a whole new
notification mechanism just for geolocation. I realize that this puts a
major burden on the DOM Events folks, who are having a hard enough time
finishing DOM3 Events, but isn't it the right thing to do?

Regarding other possible device APIs as being off-topic, I don't think so.
The W3C needs to do specifications that are forward-looking. For example,
back to DOM Events, while perhaps there are shortcomings with that
technology, at least it has proven to hold up pretty well across many
different document format languages and many different event types (e.g.,
the recent introduction of progress events).


             Doug Turner                                                   
             l.com>                                                     To 
             Sent by:                  Jon Ferraiolo/Menlo Park/IBM@IBMUS  
             public-geolocatio                                          cc 
             n-request@w3.org          Alec Berntson                       
             06/13/08 08:26 AM         <public-geolocation@w3c.org>        
                                       Re: Geolocation API                 

On Jun 13, 2008, at 7:50 AM, Jon Ferraiolo wrote:

> Two comments:
> (1) I think pretty much all device APIs (location, battery,
> connection status, SMS message queue, camera, ...) should have
> asynchronous APIs. Certainly in the general case not every API will
> be able to respond synchronously. Some implementations might require
> some network communication for either completion of the operation or
> verify identity and credentials. Since at least some of the future
> set of mobile device APIs will need to be asynchronous and that in
> at least some cases (albeit perhaps a small percentage) the
> geolocation API in particular will need to be asynchronous, I
> suggest that the geolocation API have an async design (i.e., the
> "getlocation()" method passes a callback function).

In agreement regarding async apis for Geolocation.  I do not know what
we will do with the other device APIs;  probably off topic.

> (2) For notification APIs (e.g., listenForReports()), why not use
> AddEventListener and therefore leverage DOM events?

Not a bad idea, but the current APIs are passing options when setting
up the listener.  How would you handle that?


(image/gif attachment: graycol.gif)

(image/gif attachment: pic15221.gif)

(image/gif attachment: ecblank.gif)

Received on Friday, 13 June 2008 16:17:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:49 UTC