WebAPI/WebSocketOverApps

WebSocketOverApp API provides WebSocket connections between any pair of Apps on a device. An WebApp can create WebSocket connections to other Apps on the device, so they can pass messages through the connection.

API

interface WebSocket : EventTarget {
  ...
  // The URL of the peer App.
  readonly attribute DOMString peerUrl;

  // The protocols supported by the client.
  readonly attribute DOMString[] clientProtocols;

  // The server side call this function to start a given protocol; one of clientProtocols.
  void accept(DOMString protocol);
  ...
};

clientProtocols and accept() are added to provide server side features. clientProtocols is what client side passed as the 2nd argument of WebSocket constructor. The server side can check this list to find out any one of protocols that is supported by itself. If not, just skip the request. If there is any supported protocol, call accept() to start the protocol.

The protocols, here, can be used as the intents or services provided by the server Apps.

Client Side

var ws = new WebSocket("wsapp://appid/", ["intentAsProtocol"]);
ws.onopen = function () {...};
ws.onerror = function () {...};
ws.onclose = function () {...};

Server Side

navigator.mozSetMessageHandler("wsconnect", function (request) {
  var ws = request.value;
  if (ws.clientProtocols.indexOf("intentAsProtocol") == -1) {
    // not supported
    ws.close();
    return;
  }
  ws.accept("intentAsProtocol");
  ws.onopen = function () {...}
  ws.onmessage = function () {...}
  ...
});

Manifest

{
  "name": "my application",
  ...
  "wsapp": {
    servers: ["server app1", "server app2", ...]  // allowed to connect to two Apps
  }
}

Work with DeviceIndexedDB or other Application Choosers

WebAPI/DeviceIndexedDB can be used as the API of application chooser, so we can request application chooser to return a list of applications that the user allow the app to connect to. The list returned by an application chooser can be some kind of tokens that the app can use a token as the URL to connect to.

The tokenss must be some kind of opaque data that can not be passed to other Apps, only valid for the app it-self. For security reason, the tokens should not be reversed to the server Apps, so the token holder can not tell what app it connect to by a token.

With tokens, the app can by-pass the permission checking that defined in the manifest. But, with permission checking of application choosers, an App can access only limited Apps.

Use Case