Re: Coordination

On Sat, Apr 13, 2013 at 4:23 PM, Boris Zbarsky <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.htmland
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
>