"watchPosition" misnomer? was: Re: Suggest adding proximity alarm interface

Hi all,

The thread on proximity alarms got me thinking: is "watchPosition" a  
bit of a misnomer?

One would hope that people would catch on to what it means when  
reading the Recommendation, but to a casual reader the term  
"watchPosition" may imply something closer to a proximity watch,  
rather than monitoring the hosting device for position changes.

-M


On Aug 26, 2008, at 6:52 PM, Chris Butler wrote:

>
> Hi Eric.
>
> I definitely think that proximity alerts are interesting and important
> for certain cases, but whether they fit neatly into this API is
> something we should explore more.  Here are a bunch of my thoughts
> around this...
>
> Proximity alerts seem to be for cases that you have a single map view
> and want to have one process managing what is presented (such as POI  
> on
> a view or alerts for proximity notifications) from multiple data
> sources.  This is especially true for the case that the data sources
> should probably not know about each other or have the ability to  
> affect
> each other.
>
> Another scenario this is valuable is if you want to be able to only  
> wake
> up one of many data sources or processes from the background.  This  
> does
> incur a start up and tear down cost when called, but is potentially
> better than having multiple processes running at the same time  
> fighting
> for resources.
>
> If there is only one data source with a single visual method for
> presentation, then is a proximity API better than a simple location
> watch method?  The software that is providing the geo API can decide
> things like sample clock and reduce it if necessary to reduce  
> processor
> load and/or power consumption.
>
> Now, to your justifications...
>
> Regarding reason #1, unless there are limits on what you can set for
> things like number of callbacks or maximum radius, I could just set
> something that would always be triggered.
>
> Regarding reason #2, is there really much power saved if the main cost
> is continuously checking the location via GPS (for example) rather  
> than
> processor?  Also, if you alter the clock of location samples as
> mentioned above you can save power in both cases.
>
> Regarding reason #3, it sounds like the more nuanced versions of
> 'proximity' will actually require some complex rules and would be  
> better
> for the watch functionality to handle it.
>
> Again, these are just initial thoughts with regards to proximity
> notifications in this particular API, but it is something that we have
> been thinking about here at Dash... :-)
>
> Other thoughts?
>
> Thanks.
>
> Chris
>
> -----Original Message-----
> From: public-geolocation-request@w3.org
> [mailto:public-geolocation-request@w3.org] On Behalf Of Eric Tune
> Sent: Monday, August 25, 2008 11:13 AM
> To: public-geolocation@w3.org
> Subject: Suggest adding proximity alarm interface
>
>
> I suggest adding a second set of interfaces, in addition to that set
> already defined in the draft.
> This new interface would allow an application to set an alarm which
> fires when the device's position is near a certain previously
> specified position, but which would not allow the application to
> synchronously read the position.
>
> Suggested interface:
>
> interface ProximityAlarm {
>    int setProximityAlarm(in ProximityCallback proximityCallback, in
> Position position, in Distance radius);
>    void clearProximityAlarm(in int watchId);
>  };
>
>  interface ProximityCallback {
>    void handleEvent(in Position position);
>  };
>
> Such an interface might be prefered over the current interface in some
> use cases for three reasons:
>
> 1) Sometimes a user may not trust an application to receive continuous
> updates on his position, but may trust the application enough to give
> it limited information.
> In such a case, he may wish to allow the application to access the
> ProximityAlarm interface, but not the Geolocation interface.  He would
> control this through browser preferences.
> For example, I might want to allow a "coupon" application to offer me
> coupons whenever I am in or very near a FooMart store.
> But, I'd rather that FooMart not have detailed information about my
> whereabouts at all time, as it would if it used the Geolocation
> interface.
>
> 2) The callback interface has the potential to save power, which is
> important for mobile devices.
> For example, the browser can compare the current position with all set
> alarms, and, if all are far away, it can go to sleep for a length of
> time equal to the minimum travel time to the next location.
>
> 3) A proximity interface would allow the browser to pull together
> additional information to make more nuanced judgments about proximity.
> For example, in the case of the "coupon" application, the browser
> could use both position and maps information to distinguish between
> two cases:
> a) the user is on a surface street 100m from a store where a proximity
> alarm was set, versus
> b) the user in on a freeway 50m away from said store, but, because
> there is no exit nearby.  The actual driving distance to the store is
> 2km.
> The browser might integrate position, velocity, and streetmap data,
> and adjust the effective distance, and decide to deliver the alarm in
> case "a" but not deliver the alarm in case "b".
> By contrast, if the current Geolocation api is used, each application
> would have to implement such filtering, or else provide the user with
> unwanted alerts.
>
> Eric Tune
> Software Engineer
> Google
>
>

Received on Wednesday, 17 September 2008 06:02:50 UTC