-<h3 id="live-cycle-of-plugins-within-afb-daemon">Live cycle of plugins within afb-daemon</h3>
-<p>Application and service plugins are loaded and activated each time a new afb-daemon is started.</p>
-<p>At launch time, every loaded plugin initialise itself. If a single plugin initialisation fail corresponding instance of afb-daemon self aborts.</p>
-<p>Conversely, when a plugin initialisation succeeds, it should register its unique name as well as the list of verbs attached to the methods it exposes.</p>
-<p>When initialised, on request from application clients to the right API/verb, plugin methods are activated by the afb-daemon attached to the application or service.</p>
-<p>At exit time, no special action is enforced by afb-daemon. When a specific actions is required at afb-daemon stop, developers should use 'atexit/on_exit' during plugin initialisation sequence to register a custom exit function.</p>
-<h3 id="plugin-contend">Plugin Contend</h3>
-<p>Afb-daemon's plugin register two classes of objects: names and functions.</p>
-<p>Plugins declare categories of names: - A unique plugin name to access all API expose by this plugin, - One name for each methods/verbs provided by this plugin.</p>
-<p>Plugins declare two categories of functions: - function use for the initialisation - functions implementing exposed API methods</p>
-<p>Afb-daemon parses URI requests to extract the API(plugin name) and the VERB(method to activate). As an example, URI <strong>foo/bar</strong> translates to plugin named <strong>foo</strong> and method named <strong>bar</strong>. To serve such a request, afb-daemon looks for an active plugin named <strong>foo</strong> and then within this plugin for a method named <strong>bar</strong>. When find afb-daemon calls corresponding method with attached parameter if any.</p>
+<h3 id="live-cycle-of-bindings-within-afb-daemon">Live cycle of bindings within afb-daemon</h3>
+<p>Application and service bindings are loaded and activated each time a new afb-daemon is started.</p>
+<p>At launch time, every loaded binding initialise itself. If a single binding initialisation fail corresponding instance of afb-daemon self aborts.</p>
+<p>Conversely, when a binding initialisation succeeds, it should register its unique name as well as the list of verbs attached to the methods it exposes.</p>
+<p>When initialised, on request from application clients to the right API/verb, binding methods are activated by the afb-daemon attached to the application or service.</p>
+<p>At exit time, no special action is enforced by afb-daemon. When a specific actions is required at afb-daemon stop, developers should use 'atexit/on_exit' during binding initialisation sequence to register a custom exit function.</p>
+<h3 id="binding-contend">Binding Contend</h3>
+<p>Afb-daemon's binding register two classes of objects: names and functions.</p>
+<p>Bindings declare categories of names: - A unique binding name to access all API expose by this binding, - One name for each methods/verbs provided by this binding.</p>
+<p>Bindings declare two categories of functions: - function use for the initialisation - functions implementing exposed API methods</p>
+<p>Afb-daemon parses URI requests to extract the API(binding name) and the VERB(method to activate). As an example, URI <strong>foo/bar</strong> translates to binding named <strong>foo</strong> and method named <strong>bar</strong>. To serve such a request, afb-daemon looks for an active binding named <strong>foo</strong> and then within this binding for a method named <strong>bar</strong>. When find afb-daemon calls corresponding method with attached parameter if any.</p>