RE: Suggest adding proximity alarm interface

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, 27 August 2008 01:53:24 UTC