thesis/thesis.tex: Moving automated tests to discussion section.

1 files changed, 57 insertions, 55 deletions

diff --git a/thesis/thesis.tex b/thesis/thesis.tex
index 7d752c3..cd7d1c8 100644
--- a/thesis/thesis.tex
+++ b/thesis/thesis.tex
@@ -1655,6 +1655,63 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
           relevant messages, as explained in
           \nameref{subsubsec:message_interface}.\\
 
+  \cleardoublepage
+  \section{Discussion}
+    \label{sec:discussion}
+    The \gls{osc} based networking extension created for the \gls{ssr} is a
+    valuable usability improvement. Its implemented features are discussed
+    further in the following section, followed by an outlook on related
+    future work.\\
+    Due to the versatility of how the \gls{ssr} can be used in a networking
+    context, its likely, that some of its possibilities are not even accounted
+    for.
+
+    \subsection{Implemented Features}
+      \label{subsec:implemented_features}
+      The \gls{osc} interface described in~\ref{subsec:osc-interface} can be
+      seen as a full replacement (with one minor exception, detailed
+      in~\ref{subsubsec:scene_transfer}) for the \gls{ip} interface, already in
+      place. Its additional features are what set it trully apart though, when
+      not only regarding non-reliance on external software to enable \gls{osc}
+      capabilities.\\
+
+      The implementation follows the internal \gls{pubsub} interface, as
+      described in~\ref{subsec:publisher_subscriber_interface} and extends it,
+      where appropriate. Additionally an open client-server architecture has
+      been created, according to a message level system, further elaborated
+      upon in \gls{subsubsec:message_levels}. An attempt at giving extensive
+      examples on the various setup possibilities, that are now possible, is
+      made in \gls{subsubsec:setups}, some of which are still dependant on
+      various missing features (see~\ref{subsec:future_work}).\\
+      The \gls{osc} messaging system is adhering to the aforementioned
+      client-server architecture by distinguishing between client-only,
+      server-only and messages available to clients and servers alike
+      (see~\ref{subsubsec:message_interface}). Examples for different workflows
+      are given in~\ref{subsubsec:workflow_examples} to illustrate simple
+      use-cases.\\
+      This puts the \gls{osc} interface in the unique position of providing a
+      native messaging interface and a flexible architecture. It can be used
+      from single local instances up to large scale networked setups (with the
+      limitations discussed in~\ref{subsubsec:alien_loudspeaker}
+      and~\ref{subsubsec:assigning_in_and_outputs_on_the_fly}).\\
+      While with the \gls{ip} interface, multiple instances are only
+      controllable by using an \gls{osc} capable application or one, that is
+      able to send \gls{xml}-formatted strings over \gls{tcp}/\gls{ip}, the
+      \gls{osc} interface can deal with \textit{n} clients natively, while only
+      one instance has to be controlled using \gls{osc}. The behavior implies,
+      that setups are possible, in which a large collection of different types
+      of renderers can share the same scene, which is particularly useful for
+      e.g.\ auditioning different rendering algorithms over the same system, or
+      rather in the same room.\\
+      Message sending takes place over \gls{udp}, instead of \gls{tcp}, which
+      lowers the complexity of the network topology (\gls{udp} does not perform
+      handshakes for every packet sent, unlike \gls{tcp}) and thus the size of
+      each message sent.\\
+      The \gls{osc} interface therefore implements messaging, using lower
+      bandwidth, at a greater feature set. In~\ref{subsec:automated_tests} a
+      test environment is introduced, that further elaborates on the overall
+      functionality and feasibility of the message interface.
+
     \subsection{Automated tests}
       \label{subsec:automated_tests}
       The \gls{ssr} was developed without the help of a test framework, which
@@ -1795,61 +1852,6 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         \gls{osc} message received and sent above the aforementioned verbosity
         level.
 
-  \cleardoublepage
-  \section{Discussion}
-    \label{sec:discussion}
-    The \gls{osc} based networking extension created for the \gls{ssr} is a
-    valuable usability improvement. Its implemented features are discussed
-    further in the following section, followed by an outlook on related
-    future work.\\
-    Due to the versatility of how the \gls{ssr} can be used in a networking
-    context, its likely, that some of its possibilities are not even accounted
-    for.
-
-    \subsection{Implemented Features}
-      \label{subsec:implemented_features}
-      The \gls{osc} interface described in~\ref{subsec:osc-interface} can be
-      seen as a full replacement (with one minor exception, detailed
-      in~\ref{subsubsec:scene_transfer}) for the \gls{ip} interface, already in
-      place. Its additional features are what set it trully apart though, when
-      not only regarding non-reliance on external software to enable \gls{osc}
-      capabilities.\\
-
-      The implementation follows the internal \gls{pubsub} interface, as
-      described in~\ref{subsec:publisher_subscriber_interface} and extends it,
-      where appropriate. Additionally an open client-server architecture has
-      been created, according to a message level system, further elaborated
-      upon in \gls{subsubsec:message_levels}. An attempt at giving extensive
-      examples on the various setup possibilities, that are now possible, is
-      made in \gls{subsubsec:setups}, some of which are still dependant on
-      various missing features (see~\ref{subsec:future_work}).\\
-      The \gls{osc} messaging system is adhering to the aforementioned
-      client-server architecture by distinguishing between client-only,
-      server-only and messages available to clients and servers alike
-      (see~\ref{subsubsec:message_interface}). Examples for different workflows
-      are given in~\ref{subsubsec:workflow_examples} to illustrate simple
-      use-cases.\\
-      This puts the \gls{osc} interface in the unique position of providing a
-      native messaging interface and a flexible architecture. It can be used
-      from single local instances up to large scale networked setups (with the
-      limitations discussed in~\ref{subsubsec:alien_loudspeaker}
-      and~\ref{subsubsec:assigning_in_and_outputs_on_the_fly}).\\
-      While with the \gls{ip} interface, multiple instances are only
-      controllable by using an \gls{osc} capable application or one, that is
-      able to send \gls{xml}-formatted strings over \gls{tcp}/\gls{ip}, the
-      \gls{osc} interface can deal with \textit{n} clients natively, while only
-      one instance has to be controlled using \gls{osc}. The behavior implies,
-      that setups are possible, in which a large collection of different types
-      of renderers can share the same scene, which is particularly useful for
-      e.g.\ auditioning different rendering algorithms over the same system, or
-      rather in the same room.\\
-      Message sending takes place over \gls{udp}, instead of \gls{tcp}, which
-      lowers the complexity of the network topology (\gls{udp} does not perform
-      handshakes for every packet sent, unlike \gls{tcp}) and thus the size of
-      each message sent.\\
-      The \gls{osc} interface therefore implements messaging using lower
-      bandwidth at a greater feature set.
-
     \subsection{Future Work}
       \label{subsec:future_work}
       Several features, interesting for different use-cases, could not be