Re: Proximity alarm interface

Le jeudi 30 juin 2011 à 16:35 +0100, Andrei Popescu a écrit :
> I see what you mean, although I'm not sure that's ideal from the Web
> app developer's perspective: we're presenting them with an API that,
> when called, will either fail outright,

(as geolocation would do in some circumstances, e.g. the user has asked
to remember that she doesn't want to share her location with that site)

>  generate a scary or a
> non-scary message.

(geolocation already generate a non-scary message; I would argue that in
some cases it should generate a scary message, but obviously nobody has
implemented it that way, so I agree it's a weak argument and that indeed
today geolocation would have that bit of additional reliability for
developers)

>  What motivation would they have to use it? I'm
> afraid it'll just be easier to call watchPosition() as its behavior is
> not subject to an opaque heuristic.

That's a fair point; note that one of my assumptions is that over time,
watchPosition() would come with an even scarier message, which would
make that API more attractive (in addition to the battery benefits).

Also, I think it would be reasonable to assume that UAs would use
reasonable heuristics where simple use cases  (e.g. you're only asking
for one or a few location alerts) would reliably pop up a non-scary
message.

All in all, it seems to me that there are privacy and battery benefits
in having an API on its own; they would come with some challenges, but
they feel like the type of challenges best addressed with prototypes
than abstract discussion. 

The main question would be if the use cases for that API are of high
enough priority and demand that this group (and interested browser
developers) feel like investing in these prototypes.

I tend to think it fills a useful enough gap to be worth considering,
but I can fully accept that others would not.

Dom

Received on Thursday, 30 June 2011 15:49:35 UTC