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

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

From: Doug Turner <dougt@mozilla.com>
Date: Thu, 22 Mar 2012 10:09:08 -0700
Cc: Robin Berjon <robin@berjon.com>, Frederick.Hirsch@nokia.com, public-device-apis@w3.org
Message-Id: <DF72535F-5DAB-4C5D-8E96-24FBBC390DEE@mozilla.com>
To: Dominique Hazael-Massieux <dom@w3.org>

On Mar 22, 2012, at 9:52 AM, Dominique Hazael-Massieux wrote:

> Le jeudi 22 mars 2012 à 09:49 -0700, Doug Turner a écrit :
>>>> yes, but it is simpler and follows a known pattern. 
>>> So does my proposal (it's modeled on the battery API).
>> The battery API isn't shipping everywhere.  Device orientation (and
>> soon device motion) is shipping in Firefox, Opera, and Chrome.  
> Sure; but that only shows one was started earlier than the other, not
> that it provides a better model.

No no. It is about what developers come to expect.  I have seen dozens of device orientation demos.  Lets assume that it is pretty popular.  It is on the iPhone.  It is implemented in major desktop browsers.  So many developers have seen it.  It is simple - register for a listener - done.

Now what *was* proposed in the Sensor API was inconsistent with something that works and has been deployed and is easy to use.

I am worried about consistency.  For example, consider the same developers that used device motion/orientation wants to use proximity.   It looks really familiar, but no.  they have to do extra stuff to make it work:

1) startup the device
2) possibility explicitly shutdown the device
3) use a different syntax

That is just depressing

>>> (if in fact activation-on-addEventListener is OK, I'll update
>>> http://scriptlib-cg.github.com/api-design-cookbook/ to reflect this)
>> Sure.  It is what Device Motion and Orientation is doing.  Why would
>> it now be bad for other APIs to do this?  Lets strive for consistency.
> localStorage has a design but that makes it susceptible to race
> conditions; localStorage is deployed everywhere. Would we want to adopt
> that bug nevertheless?

Don't put words in my mouth. I am not arguing that.

> A reason why we wouldn't want to do it again is if it has been proved a
> bad idea but one from which we can't easily backtrack due to existing
> deployment.

not sure I follow that you are saying here.

Received on Thursday, 22 March 2012 17:09:38 UTC

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