X-Git-Url: https://gerrit.o-ran-sc.org/r/gitweb?a=blobdiff_plain;f=doc%2Fsrc%2Frtd%2Fdeveloper-guide.xfm;h=9177cd34564ad297979172483c5a00840547784a;hb=fe6a856df463a0d7e06b28aac8590ac9c0f08dd6;hp=ebde32a8b77358ead316754c9a4bf0469de1d424;hpb=d961525e9eb23e3dee4a16960a1772782c3b8b36;p=ric-plt%2Flib%2Frmr.git diff --git a/doc/src/rtd/developer-guide.xfm b/doc/src/rtd/developer-guide.xfm index ebde32a..9177cd3 100644 --- a/doc/src/rtd/developer-guide.xfm +++ b/doc/src/rtd/developer-guide.xfm @@ -30,68 +30,76 @@ &h1(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. +&space +This document contains information that developers need to know to +contribute to the RMR project. &h2(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 &ital(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 &ital(ctypes) +library. &h2(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, &cw(librmr_nng.a) is the library generated for use with the NNG -transport. -&space +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, +&cw(librmr_nng.a) is the library generated for use with the NNG +transport. &space As such the library source is organised into multiple components: &beg_dlist(.75i : ^&bold_font ) -&di(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. +&di(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. &di(nano) Source which is tightly coupled with the underlying Nanomsg library. (Nanomsg has been deprecated, but the RMR source remains as an example.) &di(nng) Source which is tightly coupled with the underlying NNG library. + (NNG has been deprecated, but the RMR source remains as an example.) + +&di(si) Source which is tightly coupled with the underlying SI95 library. &end_dlist &space &h3(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 of the RMR functions carry a &cw(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 &cw(rmr&{esc}_,) while allowing 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 &cw(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 &cw(rmr&{esc}_). This allows internal +functions to have shorter names while still being meaningful. &h2(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 are insisted on by the maintainers of RMR, 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. &h2(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. +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.