Re: Device API organization - request for use cases/rationale

On Thu, Jan 10, 2013 at 4:16 PM, <Frederick.Hirsch@nokia.com> wrote:

>  Rick
>
>  Thanks for your feedback on the list. It is certainly worth discussing,
> in fact we discussed it on yesterday's DAP teleconference (9 Jan 2013) -
> you might want to look at the minutes when they are available.
>
>  The conclusion we reached is that we need to better understand the use
> cases driving the proposed change. There are existing implementations of
> the current approach so we need to be very clear on the use cases and
> rationale driving the need for change so we can make decisions
> understanding tradeoffs related to re-work of existing implementations and
>  benefits of the change.
>


The use cases are the same use cases that any form of DeviceFoo event would
have—the ability to write browser based programs that interact with device
(mobile and desktop) sensors. The rationale for shifting away from a single
event interface attached to the Window to a constructed Sensor.Foo
instance, that inherits from EventTarget and provides get-accessor
properties for reading values, is that the latter isn't future hostile
towards devices that might be built with more then one of any type of
sensor. The iPhone 4s and 5 added an always-on infrared LED to the
proximity sensor, that is used for "Raise to speak" detection, in addition
to detecting your face during a call. This is only one example, but devices
continue to evolve and become more sophisticated in their capabilities.
getUserMedia has already become a wart API because the designers failed to
see a future where devices had more then one camera, or that developers
would want to write programs that accessed more then one camera
simultaneously. While it appears that the spec[1] has attempted to solve
this by "advising" that multiple calls to getUserMedia can be merged into
one dialog that allows the user to initiate different/multiple streams at
once... this doesn't solve the programmer problem of knowing which stream
is which device (front? rear? camera 1? camera 2?). A constructed "Camera"
instance would've allowed the association of program object identity to
physical world object (ie. a camera) identity.

I think it's also important to remember that there is already
another precedent that shouldn't be ignored, which is the native
application APIs[2][3]. They represent different approaches, but should
serve to inform and inspire the direction of an API that is allegedly
_also_ for application programming. The direction that Tobie and I have
been pushing for appears to be at the intersection of the Android and iOS
device/sensor programming models.


Rick

[1] http://dev.w3.org/2011/webrtc/editor/getusermedia.html#handling-devices
[2] http://developer.android.com/reference/android/hardware/Sensor.html
[3]
http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIDevice_Class/Reference/UIDevice.html





>
>  Would you be able to share use cases and a summary of the rationale and
> benefit of the change to the DAP mailing list?
>
>  Thanks
>
>    regards, Frederick
>
>  Frederick Hirsch, Nokia
> Chair, W3C DAP Working Group
>
>  for tracker, ACTION-609
>
>
>
>  On Dec 18, 2012, at 11:20 AM, ext Rick Waldron wrote:
>
> While writing feedback for the Ambient Light Event specification, I found
> it hard to continue overlooking the ad-hoc reality of Device APIs in the
> browser.
>
>  Currently, sensory event APIs look like this:
>
>  DeviceOrientationEvent (incl. compassneedscalibration)
> DeviceMotionEvent
> DeviceLightEvent
> LightLevelEvent
> DeviceProximityEvent
> UserProximityEvent
>
>
>  Naming all of these "Device___Event" is unequivocally a spec/code smell.
> This is the sort of "API" mistake that we (Bocoup training and evangelism)
> see a lot of language newcomers making.
>
>  Is it too late for something like:
>
>  Device {
>   Motion
>   Light
>   LightLevel
>   Proximity
>   UserProximity
>
>    ... ?
> }
>
>  With events and property accessors:
>
>  var motion = new Device.Motion();
>
>  // via an event API
> motion.addEventListener("change", function() {
>    // ...
>  }, false);
>
>
>  // Contantly updated properties
> // (get accessor) for polling
> motion.acceration.{ x, y, z }
> motion.rotation.{alpha, beta, gamma}
>
>
>  Is this something that's worth discussing? Would it be valuable if I
> wrote a normative specification?
>
>  Rick
>
>
>
>
>