SysInfo API vs Generic Sensors API

Hi,

I've been thinking a lot recently about the potential to simplify the System
Information API [1] in to manageable implementation chunks.

In many ways, the System Information API in its current incarnation is much
the same as a Generic Sensors API should look. I could register a new
'propertyId' with the system and developers could then use that to query a
particular sensor within the device.

There is also the argument that the System Info API is not reflecting the
current implementations of its intended use cases. The Android browser today
provides a way to check the type of network that the device is currently
connected to through a navigator.connection.type object. Some web sites use
navigator.connection.type property to detect the type of network connection
(e.g. low bandwidth cellular or WiFi), in order to customize the experience,
for example with regard to media codec selection.  This is available today,
does not require prompting and allows developers to optimise content based
on perceived cost and/or bandwidth factors per connection type and to pass
on these benefits to their users (save time and/or money).

Are we missing an opportunity to standardise this much simpler API, avoiding
the need for user prompting and still covering off some of the same use
cases presented in the System Info API around network connection type in a
much simpler way?

This simpler API for determining the current network type is as follows:

// window.navigator
Navigator implements NavigatorConnection;

interface NavigatorConnection {
  readonly attribute NavigatorConnectionObj connection;
}

interface NavigatorConnectionObj
{
  // Connection types.
  const unsigned short UNKNOWN = 0;
  const unsigned short ETHERNET = 1;
  const unsigned short WIFI = 2;
  const unsigned short CELL_2G = 3;
  const unsigned short CELL_3G = 4;

  // Return the current connection type.
  unsigned short type();
}

Usage example:

<script type="text/javascript">

  var connection, connectionSpeed, htmlNode, htmlClass;

  // create a custom object if navigator.connection isn't available
  connection = navigator.connection || {'type':'0'};

  // set connectionSpeed
  switch(connection.type) {
    case connection.CELL_3G:
      // 3G
      connectionSpeed = 'mediumbandwidth';
      break;
    case connection.CELL_2G:
      // 2G
      connectionSpeed = 'lowbandwidth';
      break;
    default:
      // WIFI, ETHERNET, UNKNOWN
      connectionSpeed = 'highbandwidth';
  }

  // set the connection speed on the html element, i.e. <html
class="lowbandwidth">
  htmlNode = document.body.parentNode;
  htmlClass = htmlNode.getAttribute('class') || '';
  htmlNode.setAttribute('class', htmlClass + ' ' + connectionSpeed);

</script>

So are we missing an opportunity here to engage implementors if we don't
standardize this API and/or split the SysInfo API in to more manageable
implementation chunks?

Perhaps we can discuss at the F2F next week.

- Rich

[1] http://www.w3.org/TR/system-info-api/

Received on Friday, 29 October 2010 10:48:19 UTC