-The server side 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
+The server side 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.
\section{Integration}
\end{figure}
\section{Shares}
-The architecture of the system stores the \glspl{SDS} in the \gls{SDS} that
-stores the list 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}. When an \gls{iTasks}-\gls{Task} writes to a \gls{SDS}
-this is not passed on to the device.
-
-To solve the problem, parametric lenses are used on the device storage.
-Listing~\ref{lst:actualdev} shows the actual types for the device storage.
-Programmers wanting to access the entire \gls{SDS} use the \CI{deviceStoreNP}.
-Programmers wanting to access a single \gls{SDS} on a device can use the
-\CI{getRealShare} function which is a wrapper around the \CI{deviceStore} which
-applies a parametric lens to the \gls{SDS}.
+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}
\begin{lstlisting}[label={lst:actualdev},%
caption={Real types for the device \gls{SDS}}]
deviceStoreNP :: Shared [MTaskDevice]
deviceStore :: RWShared (Maybe (MTaskDevice, Int)) [MTaskDevice] [MTaskDevice]
-
-realDeviceStore :: Shared [MTaskDevice]
-
-getRealShare :: MTaskDevice MTaskShare -> Shared BCValue
\end{lstlisting}
\subsection{Parametric Lens}
-The type of the parametric lens is \CI{Maybe (MTaskDevice, Int)} where the
+The type of the parametric lens is \CI{Maybe (MTaskDevice, Int)}. The \gls{SDS}
+can either be focussed on the entire share, from now on global. Moreover, the
+\gls{SDS} can focus on a single device, from now on local. A local \gls{SDS}
+can also specifically focus on a single \gls{SDS} on a single device.
+
+The implementation for the share is shown in Listing~\ref{lst:shareimpl}. The
+\CI{realDeviceStore} \gls{SDS} is not exported through the header files. This
+\gls{SDS} contains the actual \gls{SDS} that writes to disk or memory.
\CI{Int} is the identifier of the \gls{SDS}. The \gls{iTasks} way of applying
lenses is through the \CI{sdsFocus} function and through the \CI{sdsLens}
functions. \CI{sdsFocus} allows the programmer to fix the parameter.
repositories / msc-thesis1617.git / blobdiff