[sensors] Introduce Generic Sensor API interfaces

device/sensors/public/interfaces/sensor.mojom

+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+module device.mojom;
+
+// Types of supported sensors
+enum SensorType {
+  FIRST = 1,
+  AMBIENT_LIGHT = FIRST,
+  PROXIMITY,
+  ACCELEROMETER,
+  GYROSCOPE,
+  PRESSURE,
+  LAST = PRESSURE // Note: LAST is also equal to the types count.
+};
+
+// Reporting mode supported by the Sensor.
+// ON_CHANGE  - client will be notified through OnSensorReadingChanged() signal
+//              whenever sensor reading is changed.
+// CONTINUOUS - sensor will continuously update its reading with frequency
+//              specified in SensorConfiguration.frequency.
+//              OnSensorReadingChanged() signal is not sent to the client for
+//              sensors with CONTINUOUS reporting mode.
+enum ReportingMode {
+  ON_CHANGE,
+  CONTINUOUS
+};
+
+struct SensorConfiguration {
+  // Frequency in Hz

[timvolodine, 2016/07/22 19:31:45]

add a comment that this is the requested frequency but not always the
guaranteed? maybe also something about max frequency

[Mikhail, 2016/08/09 19:38:28]

Done.

+  double frequency;
+  // TODO(shalamov): Add map<string, union> for sensor specific configuration.
+};
+
+// Interface for controlling the Sensor.
+interface Sensor {
+  // Requests sensor to start reading sensor data with specified
+  // SensorConfiguration.
+  // Sensor holds the list of added configurations and it always polls
+  // the platform (and updates the shared buffer) at the maxiumum frequency
+  // among the obtained from the stored configurations, so that all clients
+  // can have sensor data in time.
+  AddConfiguration(SensorConfiguration configuration) => (bool success);

[timvolodine, 2016/07/22 19:31:45]

Does the browser really need to know all 'javascript' configurations? Looking
ahead at the blink code we typically stop the sensors when page goes invisible
(I think your blink patch does that as well). So if you have 1000 sensors in
javascript when the page goes invisible you'll get 1000 RemoveConfigurations
calls and similarly 1000 AddConfigurations when it becomes visible again (if I
understand correctly).

To avoid this issue how about doing the 'multiplexing' in the renderer and using
a mojo interface something like:

Sensor {
  // can be invoked multiple times with 'override' semantics; pass null to stop
  run(SensorConfiguration?)
}

+
+  // Requests sensor to stop reading sensor data for specified
+  // SensorConfiguration.
+  // This call excludes |configuration| from the Sensor's list making it
+  // reconsider the the shared buffer udpate frequency. If there are no
+  // configurations left in the Sensor's configuration list it stops polling
+  // sensor data from the platform and update the shared buffer.
+  RemoveConfiguration(SensorConfiguration configuration) => (bool success);
+};
+
+// Interface that client of the Sensor interface must implement to observe
+// sensor reading changes and error conditions.
+interface SensorClient {
+  // Signals SensorClient when there is an error.
+  RaiseError();
+
+  // Signals SensorClient when reading has been changed (only for sensors with
+  // ReportingMode::ON_CHANGE).
+  SensorReadingChanged();
+};