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

Re: Suggest adding proximity alarm interface

From: Andrei Popescu <andreip@google.com>
Date: Mon, 15 Sep 2008 15:57:46 +0100
Message-ID: <708552fb0809150757p7914dd4atef0b235f5c86e8b2@mail.gmail.com>
To: "Chris Butler" <cbutler@dash.net>
Cc: "Eric Tune" <etune@google.com>, public-geolocation@w3.org

Hi,

I also think that the proximity alerts are very interesting but, like
Chris, I have some doubts about their suitability for this (version of
the) API. My main concern is that this functionality is quite close to
application-specific logic and, at this point, I think the main goal
of the Geolocation API is to allow such applications to be
implemented, rather than provide such rich functionality out of the
box. Having said that, if it turns out that a lot of application
developers will be asking for this feature, we should definitely
reconsider.

I also have some comments to your points:

> 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.

As Chris mentioned, we'd probably need some complicated limitation
mechanisms in place if we want to prevent applications from abusing
the API and triggering alerts very frequently.

> 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.

This sounds nice in theory, but how would the implementation determine
the "minimum travel time" in practice?

Many thanks,
Andrei
Received on Monday, 15 September 2008 14:58:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT