Re: Device API organization

Sounds good with a coherent name scheme, but maybe using Sensor rather than Device

No need to bike-shed the issue but the crystal ball is indicating that in the not to far future not all sensors that we want to access soldered to the device.

Best regards
Niklas

On 2013-01-07 15:00, "Paul Bakaus" <pbakaus@zynga.com<mailto:pbakaus@zynga.com>> wrote:



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