-.. 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.
-
-============================================================================================
-Developer's Guide
-============================================================================================
+.. 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.
+
+============================================================================================
+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
-selection is based on the message type rather than DNS host
-name-IP port combinations.
-
-This document contains information that developers need to
-know to contribute to the RMR project.
+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
+selection is based on the message type rather than DNS host
+name-IP port combinations.
+
+This document contains information that developers need to
+know to contribute to the RMR project.
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.
+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
--------------
-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,
-shortly after was ported to the third-party library NNG
-(Nanomsg Next Generation), and then was ported to an
-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.
-
-As such the library source is organised into multiple
-components:
-
- .. 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.
-
-
-
+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,
+shortly after was ported to the third-party library NNG
+(Nanomsg Next Generation), and then was ported to an
+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.
+
+As such the library source is organised into multiple
+components:
+
+ .. 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
-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\$1_``. This allows internal functions
-to have shorter names while still being meaningful.
+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
+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\$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
-existing module, respect the author's choice where style
-alternatives are not frowned upon. When creating new modules,
-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.
+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
+existing module, respect the author's choice where style
+alternatives are not frowned upon. When creating new modules,
+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
--------
-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
-comes to creating DEB/RPM packages.
+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
+comes to creating DEB/RPM packages.
Code Review / ric-plt / lib / rmr.git / blobdiff