Extend doc of RMR python binding methods
[ric-plt/xapp-frame-py.git] / docs / overview.rst
index 43d9ab2..ffac38f 100644 (file)
@@ -2,8 +2,8 @@
 .. SPDX-License-Identifier: CC-BY-4.0
 .. Copyright (C) 2020 AT&T Intellectual Property
 
-xapp-frame-py Overview
-======================
+Framework Overview
+==================
 
 This library is a framework for writing Xapps in python.
 There may or may not be many Xapps written in python; however rmr, sdl, and logging libraries all exist for python, and this framework brings them together.
@@ -14,7 +14,8 @@ RMR Xapps
 ---------
 This class of Xapps are purely reactive to rmr; data is always "pushed" to it via rmr.
 That is, every time the Xapp receives an rmr message, they do something, then wait for the next message to arrive, end never need to execute functionality at another time (if they do, use the next class).
-This is represented by a very simple callback `consume` that is invoked every time an rmr message arrives (note, this is subject to change, with more callbacks for specific messages like `A1_POLICY_REQUEST`).
+This is represented by a series of callbacks that get registered to receive rmr message types.
+Every time an rmr message arrives, the user callback for that message type is invoked, or if the user has not registered a callback for that type, their default callback (mandatory) is invoked.
 An analogy of this is AWS Lambda: "execute this code every time an event comes in" (the code to execute can depend on the type of event).
 
 General Xapps
@@ -36,6 +37,20 @@ The framework is implemented this way so that a long running client function (e.
 This is important because rmr is *not* a persistent message bus, if any rmr client does not read "fast enough", messages can be lost.
 So in this framework the client code is not in the same thread as the rmr reads, so that long running client code can never lead to lost messages.
 
+In the case of RMR Xapps, there are currently 3 potential threads; the thread that reads from rmr directly, and the user can optionally have the rmr queue read run in a thread, returning execution back to the user thread.
+The default is only two threads however, where `.run` does not return back execution and the user code is "finished" at that point.
+
+Healthchecks
+------------
+RMRXapps come with a default rmr healthcheck probe handler.
+When the RMRXapp is sent an rmr healthcheck, it will check to see if the rmr thread is healthy (well it can't even reply if it's not!), and that the SDL connection is healthy.
+The Xapp responds accordingly.
+The user can override this default handler by registering a new callback to the appropriate message type.
+
+General Xapps must handle healthchecks when they read their rmr mailbox, since there is no notion of handlers.
+
+There is no http service (Currently) in the framework therefore there are no http healthchecks.
+
 Examples
 --------
 There are two examples in the `examples` directory; `ping` which is a general Xapp, and `pong` which is an RMR Xapp.
@@ -43,12 +58,3 @@ Ping sends a message, pong receives the message and use rts to reply.
 Ping then reads it's own mailbox and demonstrates other functionality.
 The highlight to note is that `pong` is purely reactive, it only does anything when a message is received.
 Ping uses a general that also happens to read it's rmr mailbox inside.
-
-Current gaps
-------------
-The following are known gaps or potential enhancements at the time of writing.
-::
-
-    * a logger has to be provided to the xapp
-    * the ability to specify more callacks per message type?
-