}
\end{lstlisting}
-\subsection{Device Storage}
-All devices available in the system are stored in a big \gls{SDS} that contains
-a list of \CI{MTaskDevice}s. The exact specification is defined as in
-Listing~\ref{lst:mtaskdevice} accompanied with the used classes and types.
-
-The \CI{deviceResource} component of the record must implement the
-\CI{MTaskDuplex} interface that provides a function that launches a \gls{Task}
-used for synchronizing the channels. The \CI{deviceTask} stores the
-\gls{Task}-id for this \gls{Task} when active so that it can be checked upon.
-This top-level task has the duty to report exceptions and errors as they are
-thrown by setting the \CI{deviceError} field. All communication goes via these
-channels. If the system wants to send a message to the device, it just puts it
-in the channels. Messages sent from the client to the server are also placed
-in there. In the case of the \gls{TCP} device type, the \gls{Task} is just a
-simple wrapper around the existing \CI{tcpconnect} function in \gls{iTasks}. In
-case of a device connected by a serial connection, it uses the newly developed
-serial port library of \gls{Clean}\footnote{\url{%
-https://gitlab.science.ru.nl/mlubbers/CleanSerial}}.
+\section{iTasks}
+The server part of the system is written in \gls{iTasks}. Functions for
+managing devices, \glspl{Task} and \glspl{SDS} have been created to support the
+functionality. An interactive application has been created that allows an
+interactive management console for the \gls{mTask} system. This interface
+provides functionality to list \glspl{SDS}, add \glspl{Task}, remove
+\glspl{Task}, administrate devices and view the state of the system.
-Besides all the communication information, the record also keeps track of the
-\glspl{Task} currently on the device, the compiler state (see
-Section~\ref{sec:compiler}) and the according \glspl{SDS}. Finally, it stores
-the specification of the device that is received when connecting. All of this
-is given in Listing~\ref{lst:mtaskdevice}. The definitions of the message
-format are explained in the following section. Specialized shares are available
-per device. The internal mechanism for this is given in
-Chapter~\ref{chp:itasksint}.
+\subsection{Device Storage}
+All devices that have been connected to the server are stored in a \gls{SDS}.
+The \gls{SDS} contains a list of \CI{MTaskDevice}s. The \CI{MTaskDevice}
+definition is shown in Listing~\ref{lst:mtaskdevice} accompanied with the used
+classes and types.
\begin{lstlisting}[caption={Device type},label={lst:mtaskdevice}]
deviceStoreNP :: Shared [MTaskDevice]
synFun :: a (Shared Channels) -> Task ()
\end{lstlisting}
-\section{iTasks}
-The server part of the system is written in \gls{iTasks}. Functions for
-managing devices, \glspl{Task} and \glspl{SDS} have been created to support the
-functionality. An interactive application has been created that allows an
-interactive management console for the \gls{mTask} system. This interface
-provides functionality to list \glspl{SDS}, add \glspl{Task}, remove
-\glspl{Task}, administrate devices and view the state of the system.
+The \CI{deviceResource} component of the record must implement the
+\CI{MTaskDuplex} interface that provides a function that launches a \gls{Task}
+used for synchronizing the channels. The \CI{deviceTask} stores the
+\gls{Task}-id for this \gls{Task} when active so that it can be checked upon.
+This top-level task has the duty to report exceptions and errors as they are
+thrown by setting the \CI{deviceError} field. All communication goes via these
+channels. If the system wants to send a message to the device, it just puts it
+in the channels. Messages sent from the client to the server are also placed
+in there. In the case of the \gls{TCP} device type, the \gls{Task} is just a
+simple wrapper around the existing \CI{tcpconnect} function in \gls{iTasks}. In
+case of a device connected by a serial connection, it uses the newly developed
+serial port library of \gls{Clean}\footnote{\url{%
+https://gitlab.science.ru.nl/mlubbers/CleanSerial}}.
+
+Besides all the communication information, the record also keeps track of the
+\glspl{Task} currently on the device, the compiler state (see
+Section~\ref{sec:compiler}) and the according \glspl{SDS}. Finally, it stores
+the specification of the device that is received when connecting. All of this
+is given in Listing~\ref{lst:mtaskdevice}. The definitions of the message
+format are explained in the following section.
\subsection{Integration}
-When the system starts up the devices from the previous execution still
+When the system starts up, the devices from the previous execution still
residing in the \gls{SDS} must be cleaned up. It might be the case that they
contain \glspl{Task}, \glspl{SDS} or errors that are no longer applicable in
this run. A user or programmer can later choose to reconnect to some devices.
where reset d = {d & deviceTask=Nothing, deviceTasks=[], deviceError=Nothing}
\end{lstlisting}
-An image of the management interface is shown in Figure~\ref{lst:manage}.
-The system management is done by a single \gls{Task} called \CI{mTaskManager}.
-To manage the system, a couple of different functionalities are needed and
-are launched. The left sidebar of the interface shows the list of example
-\glspl{Task} that are present in the system. When clicking a \gls{Task}, a
-dialog opens in which you can select the device to send the \gls{Task} to. The
-dialog might contain user specified variables. All example \glspl{mTask} are of
-the type \CI{Task (Main (ByteCode () Stmt))} and can thus ask for user input
-first.
-
-The bottom panel shows the device information. In this panel, the devices can
-be created and modified. Moreover, this panel allows the user to reconnect with
-a device after a restart of the server application.
-
+The system's management is done through the interface of a single \gls{Task}
+called \CI{mTaskManager}. To manage the system, a couple of different
+functionalities are needed and are launched. An image of the management
+interface is shown in Figure~\ref{lst:manage}. The left sidebar of the
+interface shows the list of example \glspl{Task} that are present in the
+system. When clicking a \gls{Task}, a dialog opens in which you can select the
+device to send the \gls{Task} to. The dialog might contain user specified
+variables. All example \glspl{mTask} are of the type
+\CI{Task (Main (ByteCode () Stmt))} and can thus ask for user input first if
+needed for parameterized \glspl{mTask}. The bottom panel shows the device
+information. In this panel, the devices can be created and modified. Moreover,
+this panel allows the user to reconnect with a device after a restart of the
+server application.
+
+\todo{redo this image}
\begin{figure}[H]
\centering
\includegraphics[width=\linewidth]{manage}
\end{figure}
\subsection{Shares}
-The architecture of the system needs to keep track of the \glspl{SDS} stored on
-the client. \glspl{SDS} can be stored on only one device at the same time.
-that also stores the of devices. This means that if a \gls{SDS} updates,
-everyone watching it will be notified. This would result in to a lot of
-notifications that are not ment to be for the listener. Moreover, when a client
-updates the \gls{SDS} this is processed by the connection handler and results
-in an update of the real \gls{SDS}.
-Finally, the \gls{SDS} of a client must be synchronized with the actual device.
-There are several ways of tackling this problem each with their own pros and
-cons and their own level of abstraction.
-
-\begin{itemize}
- \item Instantiate an actual \gls{iTasks}-\gls{SDS} for every \gls{SDS} used
- in a client.
-
- \item Instantiate a \gls{iTasks}-\gls{SDS} for every device that stores all
- their \glspl{SDS}.
-
- \item Use only one \gls{iTasks}-\gls{SDS} for all devices.
-\end{itemize}
+The architecture of the system keeps track of the \glspl{SDS} stored on
+the client in the big devices \gls{SDS}. Client-\glspl{SDS} can be stored on
+one device at the same time. This means that if a \gls{SDS} updates, everyone
+watching it will be notified. This would result in to a lot of notifications
+that are not meant for the listener. Moreover, when a client updates the
+\gls{SDS} this is processed by the connection handler and results in an update
+of the real \gls{SDS}. Finally, the \gls{SDS} of a client must be synchronized
+with the actual device. Thus, when an \gls{iTasks}-\gls{Task} writes the
+client-\gls{SDS}, it must be propagated to the real device. There are several
+ways of tackling this problem each with their own pros and cons and their own
+level of abstraction.
+
+First an actual \gls{iTasks}-\gls{SDS} for every \gls{SDS} used in a client can
+be instantiated with one \gls{iTasks}-\gls{Task} listening to the \gls{SDS} and
+synchronizing it with the device when an update occured. This approach is very
+expensive as it requires a lot of listening \glspl{Task}.
+
+Improved on this, a single \gls{iTasks}-\gls{SDS} can be created for every
+devices that stores the respective \glspl{SDS}. Using the \CI{mapReadWrite}
+functions, a single \gls{SDS} per device can be created as a lens that allows
+mapping on a single client-\gls{SDS}. However, This approach still requires
+\glspl{Task} listening to the \gls{SDS} and when a \gls{SDS} is written,
+everyone is notified, even if the \gls{Task} wanted to only watch a single
+different \gls{SDS}.
+
+Ultimately, the current approach --- a single \gls{SDS} for the entire system
+--- was explored. To create \glspl{SDS} per device or per client-\glspl{SDS} a
+\CI{mapReadWrite} can be used but it suffers the same problem as mentioned
+before. Moreover, a \gls{Task} still has to watch the \gls{SDS} and communicate
+the client-\gls{SDS} updates to the actual device. Both of these problems can
+be solved using a tailor made share heavily depending on parametric lenses. The
+type signature of the share then is as listed in Listing~\ref{lst:actualdev}.
\begin{lstlisting}[label={lst:actualdev},%
- caption={Real types for the device \gls{SDS}}]
-deviceStoreNP :: Shared [MTaskDevice]
-deviceStore :: RWShared (Maybe (MTaskDevice, Int)) [MTaskDevice] [MTaskDevice]
+ caption={Device \gls{SDS}}]
+deviceStore :: Shared [MTaskDevice]
\end{lstlisting}
\subsection{Parametric Lenses}
repositories / msc-thesis1617.git / blobdiff