Re: Device API organization

From: Rick Waldron <waldron.rick@gmail.com<mailto:waldron.rick@gmail.com>>
Date: Tue, 18 Dec 2012 11:20:55 -0500
To: public-device-apis <public-device-apis@w3.org<mailto:public-device-apis@w3.org>>
Subject: Device API organization
Resent-From: <public-device-apis@w3.org<mailto:public-device-apis@w3.org>>
Resent-Date: Tue, 18 Dec 2012 16:21:51 +0000

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?

Yes please, +1000!



Rick