- From: Eric Tune <etune@google.com>
- Date: Mon, 25 Aug 2008 11:13:15 -0700
- To: public-geolocation@w3.org
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 Tuesday, 26 August 2008 10:44:55 UTC