@ -127,13 +127,13 @@ The remaining part of the client node block diagram \ref{f:client_node} not yet
\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\cite{rosen2013linux} 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\cite{adelstein2007linux}.
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\cite{adelstein2007linux}. The \texttt{lighttpd} was chosen for this task after some research, as it is the best fit for the given criteria.
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}\cite{weidner2013linux}, while \texttt{NodeMCU}\cite{kurniawannodemcu} 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.
As far as a choice for the web interface 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}\cite{weidner2013linux}, while \texttt{NodeMCU}\cite{kurniawannodemcu} is a \texttt{Lua} eco-system based on ESP-8266. Both solution are relatively mature and open-source and can be referenced easily. However, the \texttt{PHP} language was chosen, because it is the easiest way to develop the required functionality in it.
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 \gls{rdbms}\cite{sumathi2007fundamentals}. If a data-base is to be chosen, the \texttt{SQLite}\cite{allen2011definitive} 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.
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 \gls{rdbms}\cite{sumathi2007fundamentals}. If a data-base is to be chosen, the \texttt{SQLite}\cite{allen2011definitive} 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. Because there is nothing preventing us from using the Internet connection in the design, the cloud storage is chosen as a primary one and \texttt{SQLite} in stored in a local memory is used only as a backup, in case the connection cannot be established.
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\cite{van2001programming}, 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\cite{seneviratne2015internet} readily available on the Internet with and addition to (mostly) cross-compatible code, which is a nice bonus.
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\cite{van2001programming}, 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\cite{seneviratne2015internet} readily available on the Internet with and addition to (mostly) cross-compatible code, which is a nice bonus. This option has been chosen, because it is, again, the easiest way to accomplish the task.
Peter Babič
8 years ago