X-Git-Url: https://gerrit.o-ran-sc.org/r/gitweb?a=blobdiff_plain;f=docs%2Fdeveloper-guide.rst;h=db575083a2d207fff88febdb0816a9cdf8cbed04;hb=fe6a856df463a0d7e06b28aac8590ac9c0f08dd6;hp=de2bea7edaf044d153ed783c0cadbfac4c717b36;hpb=d961525e9eb23e3dee4a16960a1772782c3b8b36;p=ric-plt%2Flib%2Frmr.git diff --git a/docs/developer-guide.rst b/docs/developer-guide.rst index de2bea7..db57508 100644 --- a/docs/developer-guide.rst +++ b/docs/developer-guide.rst @@ -9,19 +9,21 @@ RMR Developer Guide ============================================================================================ -The RIC Message Router (RMR) is a library which applications -use to send and receive messages where the message routing, -endpoint selection, is based on the message type rather than -on traditional DNS names or IP addresses. This document -contains information that potential developers might need to -know in order to contribute to the 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 +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. @@ -31,12 +33,15 @@ 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 Nanosmg, and shortly after was ported -to NNG (Nanomsg Next Generation). Because RMR presents the -same API to the user application regardless of the underlying -transport library, the resulting output when compiling RMR is -a transport specific library. As an example, librmr_nng.a is -the library generated for use with the NNG transport. +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: @@ -45,8 +50,8 @@ components: common Source in the common directory is agnostic to the - underlying transport mechanism (Nanomsg or NNG), and thus - can be used when generating either library. + underlying transport mechanism (Nanomsg, NNG, SI95, ..), + and thus can be used when generating either library. nano @@ -57,6 +62,12 @@ nano 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. @@ -65,16 +76,16 @@ Internal Function Exposure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The decision to limit as much as practical the exposure of -truely internal RMR functions was made, and as a result most +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) will directly include 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\_, while allowing internal -functions to have shorter names while still being meaningful. +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 -------------------------------------------------------------------------------------------- @@ -85,9 +96,9 @@ 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 are insisted on by -the maintainers of RMR, but for the most part style is up to -the creator of a module. +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 -------------------------------------------------------------------------------------------- @@ -95,4 +106,4 @@ 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 packages. +comes to creating DEB/RPM packages.