W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2012

Device API organization

From: Rick Waldron <waldron.rick@gmail.com>
Date: Tue, 18 Dec 2012 11:20:55 -0500
Message-ID: <CAHfnhfoWxK+LEk01Jz8sgDcMoNJ5rq-BkgdoERY6GogE4H26fg@mail.gmail.com>
To: public-device-apis <public-device-apis@w3.org>
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
Received on Tuesday, 18 December 2012 16:21:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 18 December 2012 16:21:50 GMT