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

addEventListener and side effects (was: CfC to change Sensor approach, not progress current draft)

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Thu, 22 Mar 2012 17:43:38 +0100
Message-ID: <1332434618.13943.19.camel@altostratustier>
To: Doug Turner <dougt@mozilla.com>
Cc: Robin Berjon <robin@berjon.com>, Frederick.Hirsch@nokia.com, public-device-apis@w3.org
Le jeudi 22 mars 2012 à 09:36 -0700, Doug Turner a écrit :
> On Mar 22, 2012, at 9:32 AM, Dominique Hazael-Massieux wrote:
> > Le jeudi 22 mars 2012 à 09:24 -0700, Doug Turner a écrit :
> >> I am taking a much simpler approach to this whole thing.  Here is what
> >> I am doing for proximity.  It follows what we did for device motion:
> >>    https://dougturner.wordpress.com/2012/03/22/device-proximity/
> > 
> > It's simpler, but not that much simpler. One reason I took the approach
> > I mentioned is that some proximity sensors only report a boolean state
> > (near/far); without a notion of accuracy, I don't know how your proposal
> > addresses this.
> yes, but it is simpler and follows a known pattern. 

So does my proposal (it's modeled on the battery API).

> > Also, I thought the "activate-on-addEventListener" was considered a bad
> > practice based on the feedback to DeviceOrientation?
> there is precedent.  we are only sending notifications when there is a
> change.  that was the objection, iirc. 

I think the objection was more that addEventListener should not have
side-effects. See also our ISSUE-113

Now I know that there was further discussion in Geo and there was
agreement that it was OK for DeviceOrientation to proceed as is, but I
can't tell if this was because it's in fact ok to have side effects, or
if it's because the boat had already sailed (due to implementations
being available in the wild).

(if in fact activation-on-addEventListener is OK, I'll update
http://scriptlib-cg.github.com/api-design-cookbook/ to reflect this)

Received on Thursday, 22 March 2012 16:44:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:35 UTC