The server part of the system is written in \gls{iTasks}. Functions for
-managing devices, \glspl{Task} and \glspl{SDS} are available. Furthermore, an
+managing are added. This includes functionality for adding, removing and
+updating devices. Functions for sending \glspl{Task} and \glspl{SDS} to devices
+and functionality to remove them.
+Furthermore, an
interactive web application has been created that provides an interactive
-management console for the \gls{mTask} system. This interface provides
-functionality to list \glspl{SDS}, add and remove \glspl{Task}, administrate
-devices and view the state of the system.
+management console for these manageming tasks. This interface provides
+functionality to show \glspl{Task} and \glspl{SDS} and their according status.
+It also provides the user with a library of example \gls{mTask}-\glspl{Task}
+that can be sent interactively to the device.
\subsection{Device Storage}
Everything that a device encompasses is stored in the \CI{MTaskDevice} record
-type which is in turn stored in a \gls{SDS}. This includes management for the
+type which is in turn stored in an \gls{SDS}. This includes management for the
\glspl{SDS} and \glspl{Task} stored on the device. The \CI{MTaskDevice}
definition is shown in Listing~\ref{lst:mtaskdevice} accompanied with the
necessary classes and sub types. Devices added to the system must be reachable
-asynchronously. This implicates that the programmer only needs to keep hold of
+asynchronously. This implies that the programmer only needs to keep hold of
the reference to the device and not the actual device record.
-\begin{lstlisting}[caption={Device type},label={lst:mtaskdevice}]
+\begin{lstlisting}[language=Clean,caption={Device type},label={lst:mtaskdevice}]
:: Channels :== ([MTaskMSGRecv], [MTaskMSGSend], Bool)
-:: BCState = ... // Compiler state, explained in later sections
-:: MTaskDeviceSpec = ... // Also explained in later sections
-:: MTaskMSGRecv = ... // Message format, explained in later sections
-:: MTaskMSGSend = ... // Also explained in later sections
+:: MTaskDeviceSpec = ... // Explained in a later section
+:: MTaskMSGRecv = ... // Message format, explained in a later section
+:: MTaskMSGSend = ... // Also explained in a later section
:: MTaskResource
= TCPDevice TCPSettings
| SerialDevice TTYSettings
is given in Listing~\ref{lst:mtaskdevice}. The definitions of the message
format are explained in the following section.
-\subsection{Shares}
+\subsection{\glspl{SDS}}
\Glspl{SDS} on the device can be accessed by both the device and the server.
While it would be possible to only store the \glspl{SDS} on the device, this
would require a lot of communication because every read operation will then
However, this is by design and well documented. In the current system, an
\gls{SDS} can only reside on a single device.
-% TODO
% Single share per share
There are several possible approaches for storing \glspl{SDS} on the server
each with their own level of control. A possible way is to --- in the device
\CI{set} and \CI{upd} functions directory on the actual \gls{SDS}.
% Single share per device
-Another approach would be to have reference to a \gls{SDS} containing a table
-of \gls{SDS} values per device. This approach poses the same orphan problem as
-before. Accessing a single \gls{SDS} on the device happens by calling the
+Another approach would be to have reference to an \gls{SDS} containing a table
+of \gls{SDS} values per device. This approach suffers the same orphan problem
+as before. Accessing a single \gls{SDS} on the device happens by calling the
\CI{get}, \CI{set} and \CI{upd} functions on the actual table \gls{SDS} with an
-applied \CI{mapReadWrite}. Using parametric lenses can circumvent problem of
-watchers getting notified for other shares that are written. Error handling is
-better than the previously mentioned approach because a \gls{SDS} can know
+applied \CI{mapReadWrite}. Using parametric lenses can circumvent the problem
+of watchers getting notified for other shares that are written. Error handling
+is better than the previously mentioned approach because an \gls{SDS} can know
whether the \gls{SDS} has really gone because it will not be available anymore
in the table. It still does not know whether the device is still available.
The type for the parametric lens of the \gls{SDS} containing all devices is
\CI{Maybe (MTaskDevice, Int)}. There are several levels of abstraction that
have to be introduced. First, the \gls{SDS} responsible for storing the entire
-list of devices is called the global \gls{SDS}. Secondly, a \gls{SDS} can focus
-on a single device, such \glspl{SDS} are called local \glspl{SDS}. Finally, a
+list of devices is called the global \gls{SDS}. Secondly, an \gls{SDS} can focus
+on a single device, such \glspl{SDS} are called local \glspl{SDS}. Finally, an
\gls{SDS} can focus on a single \gls{SDS} on a single device. These \glspl{SDS}
are called share \glspl{SDS}. Using parametric lenses, the notifications can be
directed to only the watchers interested. Moreover, using parametric lenses,
notified. In practice, the reader only needs to be notified when the parameters
are exactly the same.
-\begin{lstlisting}[label={lst:actualdev},%
+\begin{lstlisting}[language=Clean,label={lst:actualdev},%
caption={Device \gls{SDS}}]
+($<) :: a (f a) -> (f b)
($<) a fb = fmap (const a) fb
deviceStore :: RWShared (Maybe (MTaskDevice, Int)) [MTaskDevice] [MTaskDevice]
\gls{SDS} will only be notified if a device is added or removed. The actual
code is as follows:
-\begin{lstlisting}[caption={Global \gls{SDS}}]
+\begin{lstlisting}[language=Clean,caption={Global \gls{SDS}}]
deviceStoreNP :: Shared [MTaskDevice]
deviceStoreNP = sdsFocus Nothing deviceStore
\end{lstlisting}
be notified if the device itself changed. It will not be notified when only a
single \gls{SDS} on the device changes. The implementation is as follows:
-\begin{lstlisting}[caption={Local \gls{SDS}}]
+\begin{lstlisting}[language=Clean,caption={Local \gls{SDS}}]
deviceShare :: MTaskDevice -> Shared MTaskDevice
deviceShare d = mapReadWriteError
- ( \ds->case find ((==)d) of
+ ( \ds->case find ((==)d) ds of
Nothing = exception "Device lost"
Just d = Ok d)
, \w ds->case splitWith ((==)d) ds of
a \gls{Task} writes to this \gls{SDS}, the global \gls{SDS} will know this
through the parameter and propagate the value to the device.
-\begin{lstlisting}[caption={Local \gls{SDS}}]
+\begin{lstlisting}[language=Clean,caption={Local \gls{SDS}}]
shareShare :: MTaskDevice MTaskShare -> Shared BCValue
shareShare dev share = sdsFocus ()
$ mapReadWriteError (read, write)
repositories / msc-thesis1617.git / blobdiff