Update documentation

Change-Id: Ie7c6fc98b450e0f856378b615ded2a586f02a7ad
Signed-off-by: Romain Forlot <romain.forlot@iot.bzh>

7 files changed, 67 insertions, 24 deletions

diff --git a/docs/0-Doc-Revisions.md b/docs/0-Doc-Revisions.md
index a2ae277..b496b02 100644
--- a/docs/0-Doc-Revisions.md
+++ b/docs/0-Doc-Revisions.md
@@ -4,3 +4,4 @@ Document revisions
 | Date        | Version | Designation                          | Author                  |
 |-------------|---------|--------------------------------------|-------------------------|
 | 19 Sep 2017 |   4.99-EERC1   | Initial release                      | R. Forlot [ Iot.bzh ] |
+| 11 Dec 2017 |   4.99-EERC4   | Update and add subscribe/unsubscribe instructions   | R. Forlot [ Iot.bzh ] |
diff --git a/docs/cover.jpg b/docs/cover.jpg
index 9e98734..ea03df1 100644
--- a/docs/cover.jpg
+++ b/docs/cover.jpg
diff --git a/docs/cover_small.jpg b/docs/cover_small.jpg
index c6b1f92..5fcb1de 100644
--- a/docs/cover_small.jpg
+++ b/docs/cover_small.jpg
diff --git a/docs/part-1/0_Abstract.md b/docs/part-1/0_Abstract.md
index beb610a..04dfcb2 100644
--- a/docs/part-1/0_Abstract.md
+++ b/docs/part-1/0_Abstract.md
@@ -6,4 +6,5 @@ You will find in this documentation a presentation about Signal Composer
 architecture. Signal Composer is an Application Framework binding meant to
 facilitate handling signaling, by compose, divide and create new virtuals
 signals from RAW signals coming from _low level_ binding that handle read/write,
-encode/decode on different protocols that a car could use (CAN, LIN, Ethernet, GPS, i2c, ...).
+encode/decode on different protocols that a car could use (CAN, LIN, Ethernet,
+GPS, i2c, ...).
diff --git a/docs/part-1/1-Architecture.md b/docs/part-1/1-Architecture.md
index 2a2417e..57a2927 100644
--- a/docs/part-1/1-Architecture.md
+++ b/docs/part-1/1-Architecture.md
@@ -22,7 +22,8 @@ Key here are on both layers, **low** and **high**.
  define signaling composition with simple or complex operation to output value
  from **raw** signals
 
-A transport plug-in is a shared library that shares a common API to be compatible with **low level** services that is:
+A transport plug-in is a shared library that shares a common API to be
+compatible with **low level** services that is:
 
 - **open/close**: method to open a handle which could be a socket, file or
  device by example.
@@ -50,7 +51,10 @@ Here is a little terminology guide to set the vocabulary:
 - **action**: a function called at a certain time
 - **callbacks**: a function called at a certain time
 - **event**: the raw event that materialize the signal
-- **sources**: a binding API name
+- **plugins**: a C/C++ code with functions that be called by signal composer
+ service
+- **sources**: an external binding API that generate signals for the signal
+ composer service
 - **signals**: an event generated by the **Application Framework**
 - **virtual signals**: a signal composed of **raw signals** with value
  calculated by a **callbacks**
diff --git a/docs/part-1/2-Configuration.md b/docs/part-1/2-Configuration.md
index 1bee688..5e0ca2d 100644
--- a/docs/part-1/2-Configuration.md
+++ b/docs/part-1/2-Configuration.md
@@ -1,14 +1,19 @@
 # Configuration
 
-Configuration defines all in **Signal composer** each signals and sources has to be defined in it.
-At start, configuration will be searched in default binding configuration directory which should be
-_/var/lib/afm/applications/signal-composer/1.0/etc/_. Binding search for a file name as _init-daemon*.json_. Others files could be used to split sections and don't have 1 big fat definitions file.
+Configuration defines all in **Signal composer** each signals and sources has
+to be defined in it. At start, configuration will be searched in default
+binding configuration directory which should be _/var/lib/afm/applications/signal-composer/1.0/etc/_.
+Binding search for a file name as _init-daemon*.json_. Others files could be
+used to split sections and don't have 1 big fat definitions file.
 
 Saying that you have 4 sections to define:
 
-- **metadata**: Main parts and the only one that can't be in a separates configuration. This must appears in the main configuration file.
-- **plugins** (optionnal): Declare plugins that will be used by *sources* and *signals* for the subscription and composition.
-- **sources**: Declare **low level** signals sources (eg. low-can, gps, mraa, ...).
+- **metadata**: Main parts and the only one that can't be in a separates
+ configuration. This must appears in the main configuration file.
+- **plugins** (optionnal): Declare plugins that will be used by *sources* and
+ *signals* for the subscription and composition.
+- **sources**: Declare **low level** signals sources (eg. low-can, gps, mraa,
+ ...).
 - **signals**: Declare signals, virtuals and raw.
 
 ## Metadata
@@ -16,30 +21,34 @@ Saying that you have 4 sections to define:
 Here we define some metadata about **signal composer** binding. Fields to configure
 are :
 
-- **label**: self-explanatory
+- **uid**: self-explanatory
 - **version** (optionnal): self-explanatory
-- **api**: name that the binding will be initialized to and later be accessible by **Application Framework**
+- **api** (optionnal): name that the binding will be initialized to and later
+ be accessible by **Application Framework**
 - **info** (optionnal): self-explanatory
 - **require** (optionnal): list of required external apis.
-- **files** (optionnal): list of additionnals files. **ONLY NAME** or part of it without extension. These
- files are loaded to find sections: *plugins*, *sources* and *signals*.
 
 ## Plugins
 
-This section is the only which is optionnal, it is needed if you develop specifics C/C++ plugins
-to be used with signal-composer. LUA and API consumption does not need plugins.
+This section is the only which is optionnal, it is needed if you develop
+specifics C/C++ plugins to be used with signal-composer. LUA and API
+consumption does not need plugins.
 
-Default path to search for a plugin is in the binding library directory in a subdirectory _plugins_
-_/var/lib/afm/applications/signal-composer/1.0/lib/plugins_. Else you could use the environment variable _CONTROL_PLUGIN_PATH_ with a semicolon separated list of
-directory.
+Default path to search for a plugin is in the binding library directory
+in a subdirectory _plugins_ _/var/lib/afm/applications/signal-composer/1.0/lib/plugins_.
+Else you could use the environment variable _CONTROL_PLUGIN_PATH_ with a
+semicolon separated list of directory.
 
 Fields are:
 
-- **label**: Define the plugin name. This is that label that will be used on **sources** and
- **signals** callbacks.
-- **version** (optionnal): self-explanatory
+- **uid**: Define the plugin name. This is that label that will be used on
+ **sources** and **signals** callbacks.
+- **ldpath** (optionnal): path to the plugin directory
 - **info** (optionnal): self-explanatory
 - **basename**: shared library file name **without** the extension.
+- **files** (optionnal): list of additionnals files. **ONLY NAME** or part of
+ it, without extension. Don't mix up section object with this key, either one
+ or the other but avoid using both
 
 ## Sources
 
@@ -49,13 +58,18 @@ thinning,... and create new virtuals signals composed with basic raw signals.
 
 A source is defined with following fields:
 
+- **uid**: An unique identifier name for thatuid source API.
 - **api**: Name of the source API.
 - **info** (optionnal): self-explanatory
 - **init** (optionnal): an **action** to take to initialize a source. May you
  have  to call a verb from that API, of create a files etc.
 - **getSignals** (optionnal); an **action** to take to get signals from that
- source. These callback will be used for each signals defined later in the **signals** section. Dedicated arguments for each signal could be defined in
+ source. These callback will be used for each signals defined later in the
+ **signals** section. Dedicated arguments for each signal could be defined in
  **signals**.
+- **files** (optionnal): list of additionnals files. **ONLY NAME** or part of
+ it, without extension. Don't mix up section object with this key, either one
+ or the other but avoid using both
 
 ## Signals
 
@@ -63,13 +77,14 @@ A signal definition could be either a **raw** one or a **virtual** one. A
  **virtual signal** is a set of existing **raw signals** associated to an
  **action** on reception which will compute the value of the signal.
 
-- **id**: Unique identifier used inside **signal composer**, used to compose
+- **uid**: Unique identifier used inside **signal composer**, used to compose
  virtual signals.
 - **event**: specify a **raw signal** coming from **low level** sources.
  Couldn't be used with **depends** field, only one of them is possible.
 - **depends**: specify others signals **id** that compose it (eg: heading is
  composed with longitude+latitude signals.). Couldn't be used with **event**
  field at same time.
+- **retention** (optionnal): retention duration in seconds
 - **unit** (optionnal): Unit used to exprime the signal
 - **frequency** (optionnal): Frequency maximum at which the signal could be
  requested or sent. This is a thinning made at **high level** so not best
@@ -79,3 +94,6 @@ A signal definition could be either a **raw** one or a **virtual** one. A
  filtering capabilities at subscription and to be able to customize in general
  a subcription request by signal if needed.
 - **onReceived**: an **action** to take when this signal is received!
+- **files** (optionnal): list of additionnals files. **ONLY NAME** or part of
+ it, without extension. Don't mix up section object with this key, either one
+ or the other but avoid using both
diff --git a/docs/part-1/4-SignalComposerAPI.md b/docs/part-1/4-SignalComposerAPI.md
index 00dbae4..dc47f01 100644
--- a/docs/part-1/4-SignalComposerAPI.md
+++ b/docs/part-1/4-SignalComposerAPI.md
@@ -1,5 +1,24 @@
 # Signal Composer API
 
+## subscribe/unsubscribe
+
+Using subscribe you can get update on change for signals you chose and you can
+using wildcard to subscribe several signals in the same time.
+
+```json
+signal-composer subscribe {"signal": "rear_left*"}
+ON-REPLY 1:signal-composer/subscribe: {"jtype":"afb-reply","request":{"status":"success","uuid":"3d4b743b-7ac6-4d3c-8fce-721107f9dee5"}}
+```
+
+Then event comes up like the following:
+
+```json
+ON-EVENT signal-composer/257b343e-8ea9-4cd7-8f9e-1904fa77f8f2({"event":"signal-composer\/257b343e-8ea9-4cd7-8f9e-1904fa77f8f2","data":{"uid":"rear_left_door","event":"low-can\/messages.doors.rear_left.open","timestamp":4833910845032292484,"value":false},"jtype":"afb-event"})
+```
+
+Unsubscribe happens the same way. When no more signals are holded by the client
+then it unsubscribe from the *AGL Application Framework* event handle.
+
 ## get
 
 You can get a signal value be requesting the API with the verb *get*:
@@ -29,5 +48,5 @@ Verb **loadConf** let you add new files to be able to add new **sources** or
 **signals**.
 
 ```json
-signal-composer loadConf {"filepath": "/path/to/your/json/file.json"}
+signal-composer loadConf {"file": "/path/to/your/json/file.json"}
 ```