W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2012

Re: [sensors] Proximity Events

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Mon, 21 May 2012 17:09:38 +0200
To: Robin Berjon <robin@berjon.com>
Cc: Doug Turner <dougt@mozilla.com>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <j1kkr7d8f2ib7l6mi36jk5gsfvvfg32foc@hive.bjoern.hoehrmann.de>
* Robin Berjon wrote:
>On May 16, 2012, at 21:40 , Doug Turner wrote:
>> Basically yes.  You can think of a system where the proximity sensor is
>> always on (in practice we don't do this).  When someone registers for an
>> event, there is a state change from unknown->known.  We fire this as a
>> proximity event to the registered event listener.
>
>I'm happy with this solution, and Jonas's arguments make a lot of sense.
>
>I would just like to make sure that we all agree that this is different
>from "ISSUE-113: AddEventListener in Battery Status has side effects"
>[0]. We closed that issue because Battery ended up using a different
>design for which the problem did no manifest, but we didn't reach
>consensus on whether this was a good thing or not. If it's not different
>and the same issue applies here, the "right" thing to do would be to
>prod those who thought it a bad design (Anne comes to mind) so that they
>may voice their concerns.

It's the same problem and suffers from the same conceptual flaw (if you
add a second listener there is no reason to trigger the first listener).
http://lists.w3.org/Archives/Public/public-geolocation/2011Nov/0016.html
was the last I heard about the matter I believe.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Monday, 21 May 2012 15:10:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 21 May 2012 15:10:33 GMT