Breach modular architecture

This pages describes Breach modular architecture.

Module Storage, Versioning and Discovery

The module architecture is based on GitHub, a module being a public GitHub repository. Modules are referenced by github URLs path {user|organization}/{repository}. This lets users activate a module simply by providing its GitHub path. Version information can be attached to a module through the use of git tags with the syntax vXX.YY.ZZ.

Unless specified by version, a module will be automatically updated by breach. The user shall be prompted of such updates before they take place. Breach tracks version of a module thanks to the tag information available on the module Github repository.

Module Discovery is not in the scope of this specification. It could be entirely outsourced to third parties or provided by breach.cc and accessible from Breach itself. (See npm, vim scripts, etc... for inspiration). An early version of module discovery could be accomplished using the public GitHub search API.

Module Architecture

Modules run in a separate process. This offers isolation with the main Breach process and permits the enforcement of ACLs on what a module can or cannot do with the browser. For now modules are not sandboxed and have full access to the NodeJS APIs.

A module is in charge of displaying a specific control to the user while using the Breach Browser and/or injecting CSS/JS into webpages visited and/or simply tracking the usage of the Browser. The creation of entirely standalone apps using the Breach modulare architecture is out of scope.

Breach provides a core module in charge of navigation (tabs, navigation state, ...), and related data storage (cookies, localstorage, indexedDB, etc...). The core module also exposes an API for other modules to alter and act upon the navigation state.

Module API

The module API provides a inter-module RPC and Eventing API. Modules can register for and emit messages. They can also expose asynchronous procedures that can be invoked cross-process by other modules.

var breach = require('breach_module');

breach.emit(type, evt);
var rid = breach.register('mod_test', 'foo');
breach.module('mod_test').on('foo', function(evt) {});

breach.unregister(rid);

breach.expose(proc, function(src, args, cb_) {});
breach.remove(proc);

breach.module('mod_test').call('test', args, function(err, result) {});

The register accepts regular expressions for the module and type arguments. This will enable modules that don't know each others to communicate by using common conventions (as an example an URL box value update):

breach.register(/.*/, 'box:value', function(msg) {});

Two special procedures will be called by the module manager init and kill whenever the browser is initializing and shutdowning.

Given the semantics of the module API, browser related objects will be referenced by string ids (frame_id, session_id, etc...).

The Core Module

Breach exposes its own breach/core module for other module to interact with the core functionalities of the browser. The breach/core module exposes the navigation state, the ability to display controls, the ability to control pages.

var core = breach.module('breach/core');
core.call('create_control', {
  url: 'http://localhost:1234'
}, function(err, control_id) {
  core.call('show_control', {
    control_id: control_id,
    type: 'TOP',
    dimension: 200
  });
});

breach.register('breach/core', 'state:change', function(state) {});

// ...