Skip to content

Conversation

@tobie
Copy link
Member

@tobie tobie commented Jun 11, 2015

This is new API proposal that tries to account for the various issues raised so far, notably problems around discoverability. Please bear with the quickly cobbled together document. I'm really trying to get the big picture right here, before diving into the details once the basic outline settles.

You can read it in full here for the time being.

Here's what a UML-ish representation would look like (for those of you to which these things speak):

image

Alternative solution

Note that another API design option merges Sensor and SensorObserver together and add start() and stop() methods to it (thus allowing creating new Sensor objects without immediately polling the sensors).

[Constructor, Exposed=(Window,Worker)]
interface Sensors {
  Promise<sequence<Sensor>> matchAll(optional MatchAllOptions options);
};

partial interface Window {
  [SameObject] readonly attribute Sensors sensors;
};

partial interface WorkerGlobalScope {
  [SameObject] readonly attribute Sensors sensors;
};

dictionary MatchAllOptions {
  DOMString type;
};

[Constructor(optional SensorOptions SensorOptions), Exposed=(Window,Worker)]
interface Sensor : EventTarget {
  readonly attribute double frequency;
  readonly attribute boolean batch;
  readonly attribute boolean isDefault;
  readonly attribute DOMString identifier;
  readonly attribute TresholdCallback? treshold; 
  readonly attribute double timeout; 
  readonly attribute booelan wakeup; 
  readonly attribute SensorReading? value;
  readonly attribute SensorReading[]? values;
  void start();
  void stop();
  attribute EventHandler onerror;
  attribute EventHandler onchange;
  // would that cover all cases?
  attribute EventHandler oncalibration;
  // needed?
  attribute EventHandler onconnect;
  attribute EventHandler ondisconnect;
};

dictionary SensorOptions {
  DOMString? identifier;
  boolean? isDefault = false;
  double? frequency;
  boolean? batch = false;
  TresholdCallback? treshold;
  double? timeout;
};

callback TresholdCallback = boolean (SensorReading currentValue, SensorReading newValue);
sensors.matchAll({ type: "proximity", position: "rear" }).then(function(sensors) {
    var sensor = sensors[0];
    if (!sensor) return;
    // sensor.consructor === ProximitySensor;
    sensor.onchange = dostuff;
    sensor.start();
});

And again, for the more visual among us:

image

Extensibility

Here's what extending either of these proposals would look like to create, for example, a proximity sensor:

[Constructor(optional ProximitySensorOptions proximitySensorOptions), Exposed=(Window,Worker)]
interface ProximitySensor : Sensor {
  readonly attribute ProximitySensorReading? value;
  readonly attribute ProximitySensorReading[]? values;
};

interface ProximitySensorReading : SensorReading {
    readonly attribute unrestricted double distance;
};

dictionary ProximitySensorOptions : SensorOptions {
    double? min = -Infinity;
    double? max = Infinity;
};

image

@marcoscaceres
Copy link
Member

general comment: can we please do something about the line lengths? It makes changes hard to review as there is no soft-wrap option :( At least, use natural breaks at each "."

index.html Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concrete sensor implementation will need to subclass this.

That sounds strange - avoid the word "this" :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the prose is terrible throughout this proposal, in my defense, though, I actually put it together 30 minutes before presenting it on the call. It's insight about the proposed architecture I'm really interested in at this point, as maybe people will find it terrible (and possibly rightfully so!).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need this as an option. Can't this be a listener on the observer? Having it as a listener on the observer allows for more than one callback. It also allows it to be cleared, etc.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would need to stop propagation and things which afaik is registration order dependent, no? I need to think about this more (there's an issue for that: #25).

@marcoscaceres
Copy link
Member

Looking good 💃

tobie added a commit that referenced this pull request Sep 23, 2015
Updated proposal for Sensor API
@tobie tobie merged commit da17fc8 into w3c:gh-pages Sep 23, 2015
@tobie
Copy link
Member Author

tobie commented Sep 23, 2015

Merged this although I'm going to make a large number of changes on top of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants