Rick Waldron on DeviceAmbientLightEvent, DeviceMagneticFieldEvent, DeviceProximityEvents

FYI; archive is 
<http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0097.html>.

-------- Original Message --------
Subject: 	Re: Coordination
Resent-Date: 	Sat, 13 Apr 2013 20:56:32 +0000
Resent-From: 	<public-script-coord@w3.org>
Date: 	Sat, 13 Apr 2013 16:55:44 -0400
From: 	ext Rick Waldron <waldron.rick@gmail.com>
To: 	Boris Zbarsky <bzbarsky@mit.edu>
CC: 	public-script-coord@w3.org <public-script-coord@w3.org>






On Sat, Apr 13, 2013 at 4:23 PM, Boris Zbarsky <bzbarsky@mit.edu 
<mailto:bzbarsky@mit.edu>> wrote:

    On 4/13/13 2:33 PM, Rick Waldron wrote:

        Yes, you're right. I'm sorry for over generalizing and I hope
        that you
        and Chaals will accept my apology.


    All is forgiven on my end.

    One other thing I think is worth thinking about, in this thread, is
    that new APIs aren't just bad as idiomatic JS, they're often bad in
    all sorts of other ways (e.g. don't even check whether their IDL
    makes sense or is valid).  What we really need to be doing is being
    more careful in API design across the spectrum, and that includes
    more care about how it looks in JS, than we have been, I think.

    The problem is that this needs either an editor who really cares
    (which happens, but not always) or feedback as the spec is worked
    on.  And for the latter, I've found that the #1 thing that leads to
    no feedback is that no one knows the spec is being worked on, hence
    the proposals to at least formalize "hey, there's this thing"
    notifications...  We can and should try to do better than that, I
    think, but that should be a bare minimum requirement for specs to
    proceed that we can implement immediately.


I agree with and greatly appreciate everything single word you've 
written here.

An experience I had...

The DeviceAmbientLightEvent and DeviceMagneticFieldEvent "API"s were 
presented as:

1. A spec that had already been implemented
2. A spec that was copied from the poorly designed 
DeviceOrientationEvent and DeviceMotionEvent, to claim  "platform 
consistency"


DeviceMagneticFieldEvent proposal announcement here: 
http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0072.html

My feedback: 
http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0075.html 
...The follow up responses support my earlier claims that "platform 
consistency" is the silver bullet of easy feedback dismissal

DeviceAmbientLightEvent feedback thread: 
http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0052.html 
. The closest thing I could find to a proposal announcement is here: 
http://lists.w3.org/Archives/Public/public-device-apis/2012Aug/0066.html

My feedback: 
http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0059.html 
(this lead to the more comprehensive post listed below)

DeviceProximityEvent proposal announcement: 
http://lists.w3.org/Archives/Public/public-device-apis/2012May/0186.html 
and a later feedback thread: 
http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0016.html

My feedback: 
http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0024.html

Following up on that, I posted arguments against the current design of 
all Device*Event/sensory APIs:

- http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0060.html
- http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0037.html

(Based on experience designing JS-friendly APIs for async hardware 
programming)

tl;dr:

- The "window" is in an inappropriate event target for device events. 
The "browser window" does not know what "user proximity" means.
- The current designs ignore the possibility of more then one of any 
kind of sensor (there are already two cameras and two proximity sensors 
on most devices). The solution IS NOT to put a mutable property with a 
string value as in "id" on the event object.
- There is no way to "ask" the device what its initial or current 
value/reading is (must wait for an event)
- Objectively, the data model is wrong, ie. there is no data model for a 
sensor, just an event object.


I should note that Anssi did ask for me to prepare alternate proposals 
(http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0038.html), 
and Doug Turner did seem somewhat interested. Any motivation and 
momentum was killed upon learning that implementors weren't interested 
in doing better: 
http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/att-0024/minutes-dap-2013-01-09.html#item06 
. Marcos and I still need to wrap up our alternate spec, but there is no 
rush now.



Rick



    -Boris

Received on Sunday, 14 April 2013 11:10:09 UTC