W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2013

Re: Device API organization

From: Paul Bakaus <pbakaus@zynga.com>
Date: Mon, 7 Jan 2013 14:00:22 +0000
To: public-device-apis <public-device-apis@w3.org>
Message-ID: <CD10934A.18242%pbakaus@zynga.com>


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
Received on Monday, 7 January 2013 14:00:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:57 UTC