Add route table guide and formatting tweaks
[ric-plt/lib/rmr.git] / docs / developer-guide.rst
index ecaab1f..bdd8964 100644 (file)
@@ -1,16 +1,17 @@
 .. This work is licensed under a Creative Commons Attribution 4.0 International License. 
 .. SPDX-License-Identifier: CC-BY-4.0 
 .. CAUTION: this document is generated from source in doc/src/rtd. 
 .. To make changes edit the source and recompile the document. 
 .. Do NOT make changes directly to .rst or .md files. 
  
-RMR Developer Guide 
 ============================================================================================ 
+Developer's Guide 
+============================================================================================ 
+
+
+OVERVIEW
+========
+
 The RIC Message Router (RMR) is a library for peer-to-peer 
 communication. Applications use the library to send and 
 receive messages where the message routing and endpoint 
@@ -19,20 +20,22 @@ name-IP port combinations.
  
 This document contains information that developers need to 
 know to contribute to the RMR project. 
-Language 
--------------------------------------------------------------------------------------------- 
+
+
+Language
+--------
+
 RMR is written in C, and thus a contributing developer to the 
 core library should have an excellent working knowledge of C. 
 There currently is one set of cross-languages bindings 
 supporting Python, and a developer wishing to contribute to 
 the bindings source should be familiar with Python (version 
 3.7+) and with the Python *ctypes* library. 
-Code Structure 
--------------------------------------------------------------------------------------------- 
+
+
+Code Structure
+--------------
+
 RMR is designed to provide an insulation layer between user 
 applications and the actual transport mechanism. Initially 
 RMR was built on top of the third-party library Nanosmg, 
@@ -42,56 +45,63 @@ internally developed socket library called SI95. RMR presents
 the same API to the user application regardless of the 
 underlying transport library, but the resulting output when 
 compiling RMR is always a transport-specific library. As an 
-example, librmr_nng.a is the library generated for use with 
-the NNG transport. 
+example, ``librmr_nng.a`` is the library generated for use 
+with the NNG transport. 
  
 As such the library source is organised into multiple 
 components: 
  
-common 
-   
-  Source in the common directory is agnostic to the 
-  underlying transport mechanism (Nanomsg, NNG, SI95, ..), 
-  and thus can be used when generating either library. 
-nano 
-   
-  Source which is tightly coupled with the underlying 
-  Nanomsg library. (Nanomsg has been deprecated, but the RMR 
-  source remains as an example.) 
-nng 
-   
-  Source which is tightly coupled with the underlying NNG 
-  library. (NNG has been deprecated, but the RMR source 
-  remains as an example.) 
-si 
-   
-  Source which is tightly coupled with the underlying SI95 
-  library. 
-Internal Function Exposure 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
+   .. list-table:: 
+     :widths: auto 
+     :header-rows: 0 
+     :class: borderless 
+      
+     * - **common** 
+       - 
+         Source in the common directory is agnostic to the underlying 
+         transport mechanism (Nanomsg, NNG, SI95, ..), and thus can be 
+         used when generating either library. 
+      
+     * - **nano** 
+       - 
+         Source which is tightly coupled with the underlying Nanomsg 
+         library. (Nanomsg has been deprecated, but the RMR source 
+         remains as an example.) 
+      
+     * - **nng** 
+       - 
+         Source which is tightly coupled with the underlying NNG 
+         library. (NNG has been deprecated, but the RMR source remains 
+         as an example.) 
+      
+     * - **si** 
+       - 
+         Source which is tightly coupled with the underlying SI95 
+         library. 
+          
+
+
+Internal Function Exposure
+--------------------------
+
 The decision to limit as much as practical the exposure of 
 truly internal RMR functions was made, and as a result most 
-of the RMR functions carry a static label. In order to 
+of the RMR functions carry a ``static`` label. In order to 
 modularise the code as much as possible, this means that the 
 primary module (e.g. rmr_nng.c) directly includes other RMR 
 modules, rather than depending on referencing the internal 
 functions during linking. While this is an infrequently used 
 approach, it does mean that there are very few functions 
 visible for the user application to reference, all of them 
-having the prefix rmr\_. This allows internal functions to 
-have shorter names while still being meaningful. 
-Coding Style 
--------------------------------------------------------------------------------------------- 
+having the prefix ``rmr\$1_``. This allows internal functions 
+to have shorter names while still being meaningful. 
+
+
+Coding Style
+------------
+
 There is a list of coding style guidelines in the top level 
 directory, and as such they are not expanded upon here. The 
 general practice is to follow the style when editing an 
@@ -101,10 +111,11 @@ select a style that fits the guidelines and is easy for you
 to work with. There are a few things that the RMR maintainers 
 insist on, but for the most part style is up to the creator 
 of a module. 
-Building 
--------------------------------------------------------------------------------------------- 
+
+
+Building
+--------
+
 RMR is constructed using CMake. While CMake's project 
 description can be more cumbersome than most typical 
 Makefiles, the tool provides convenience especially when it