Add the SW breakdown sub-chapter

SW components considerations with an arduino glossary entry.

analytical.tex

@@ -97,3 +97,20 @@ For the protection against fire a standard electric fuse or self-regenerative fu
 
 The remaining parts of the client node block diagram \ref{f:client_node} not yet mentioned are switching and sound indication. Either a mechanical relay or a semiconductor device, such as a thyristor or a \gls{ssr} isolated by an opto-coupler will do. Mechanical relays tend to be larger and produce sound noise, have slow response time, but have inbuilt separate isolation and are capable of switching higher currents without additional thermal issues than their semiconductor counterparts. The disadvantages of the mechanical relay are not relevant here, thus the choice is obvious.
 
+
+\subsection{Software components breakdown}
+As with the hardware components, again, starting with the server node, the board should work alongside the \textbf{OpenWRT} \gls{os}, again, described in a deeper detail in the sub-chapter \ref{ss:openwrt}. It allows for relatively easily configurable network connections and the web-server.
+
+The web-server should be handled by some package already available for installation into the OpenWRT distribution. There are various choices. Ordered in an ascending order by their complexity, the most common ones are: \texttt{uhttpd}, \texttt{lighttpd}, \texttt{Apache} and \texttt{nginx}. The resource requirements are proportional to the complexity, and since GL.inet is not an extremely powerful machine, the choice should fall on the more lightweight one from the beginning of the list, with just as many features as absolutely necessary.
+
+As far as a choice for the programming/scripting language goes, there are three rather good choices: \texttt{Python}, \texttt{PHP} and \texttt{Lua}. There is no exact way to choose - it all depends on the confidence and the efficiency of the implementer, which one fits the best. Any available language will do. However, it should be noted, that \texttt{Lua}, is somewhat superior choice, since two influential software solutions for the proposed system are written in it. On the side of the OpenWRT, we are speaking about the web configuration interface called \texttt{LuCi}, while \texttt{NodeMCU} is a \texttt{Lua} eco-system based on ESP-8266. Both solution are relatively mature and open-source, so the programmer can refer to them easily.
+
+Another choice lies in the way of storing the measured data on the server. For a local storage, one can either use plain text format for very simple data, or a data-base of some sort, preferably a relational one. If a data-base is to be chosen, the \texttt{SQLite} is a good choice - it was already noted, that the computational resources are at premium. Everything marketed as lightweight has an edge here. For a remote storage, there is a plethora of cloud-based solutions, ready to employ and use, so this is a very good choice, if an internet  connection is available. 
+
+On a client side of a proposed system, there are again three main language options. The first one is the already mentioned \texttt{Lua}. This language is simple, yet not terribly popular. The availability of the design resources might be limited. Second one is the ruler of the micro-controller world, plain \texttt{C}, suited for more experienced programmer, but providing the highest flexibility. The third choice is to use \texttt{C++} based eco-system, derived from \Gls{arduino}. This choice is far more superior, because it provides access to enormous resources and libraries readily available on the Internet with and addition to (mostly) cross-compatible code, which is a nice bonus.
+
+
+
+
+
+

glossaries.tex

@@ -181,3 +181,7 @@
 	name=memory,
 	description={In computing, refers to the computer hardware devices used to store information for immediate use}
 }
+\newglossaryentry{arduino}{
+	name=arduino,
+	description={common term for a software company, project, and user community that designs and manufactures computer open-source hardware, open-source software, and microcontroller-based kits for building digital devices and interactive objects that can sense and control physical devices}
+}