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

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.

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