The goal of the system as a whole is to offer a framework of functions with
which an \gls{iTasks}-system can add, change and remove devices at runtime.
-Moreover, the \gls{iTasks}-system can send \glspl{mTask} --- compiled at
-runtime to bytecode by the \gls{mTask}-view --- to the device. The device runs
-an interpreter which can execute the \gls{Task}'s bytecode. Device profiles
-should be persistent during reboots of the \gls{iTasks}-system. The methods of
-interacting with \glspl{mTask} should be analogous to interacting with
-\gls{iTasks}-\glspl{Task}. This means that programmers can access the
-\glspl{SDS} made for a device in the same way as regular \glspl{SDS} and they
-can execute \gls{mTask}-\glspl{Task} as if they where normal
+Moreover, the \gls{iTasks}-system can send \gls{mTask}-\glspl{Task} ---
+compiled at runtime to bytecode by the \gls{mTask}-view --- to the device. The
+device runs an interpreter which can execute the \gls{Task}'s bytecode. Device
+profiles should be persistent during reboots of the \gls{iTasks}-system. The
+methods of interacting with \gls{mTask}-\gls{Task} should be analogous to
+interacting with \gls{iTasks}-\glspl{Task}. This means that programmers can
+access the \glspl{SDS} made for a device in the same way as regular \glspl{SDS}
+and they can execute \gls{mTask}-\glspl{Task} as if they where normal
\gls{iTasks}-\glspl{Task}.
The following terms will be used throughout the following chapter:
\glspl{SDS} and the size of the stack.
\begin{lstlisting}[label={lst:devicespec},
- caption={Device specification for \glspl{mTask}}]
+ caption={Device specification for \gls{mTask}-\glspl{Task}}]
:: MTaskDeviceSpec =
{ haveLed :: Bool
, haveLCD :: Bool
\subsection{Shares}
The system keeps track of the \glspl{SDS} stored on
the client in a big \gls{SDS} containing a list of devices. Client-\glspl{SDS}
-can be stored on one device at the same time. This means that if a \gls{SDS}
+can be stored on one device at the same time. This means that if an \gls{SDS}
updates, everyone watching it will be notified. This would result in a lot
of notifications that are not meant for the watcher. Moreover, when a client
updates the \gls{SDS} this is processed by the connection handler and results
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,
+\glspl{Task} listening to the \gls{SDS} and when an \gls{SDS} is written,
everyone is notified, even if the \gls{Task} only uses the value of a single
different \gls{SDS}.
\CI{mapReadWrite} can be used but it suffers from 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 by using a tailor made share that heavily depends on parametric
+be solved by using a tailor made \gls{SDS} that heavily depends on parametric
lenses.
\subsection{Parametric Lenses}
The \gls{SDS} is a lens on an actual \gls{SDS} that writes to a file or memory.
Reading the \gls{SDS} is nothing more than reading the real \gls{SDS}. Writing
the \gls{SDS} is a little bit more involved. If the write operation originated
-from a \gls{SDS} focussed on a single client-\gls{SDS}, the write action must
-also be relayed to the actual device. If the write originated from a \gls{SDS}
+from an \gls{SDS} focussed on a single client-\gls{SDS}, the write action must
+also be relayed to the actual device. If the write originated from an \gls{SDS}
focussed the devices or on one device only, nothing needs to be done. The
notification predicate determines whether a watcher gets a notification update.
$ sdsFocus (Just (d, -1)) deviceStore
\end{lstlisting}
-\subsubsection{Local-share specific \glspl{SDS}}
+\subsubsection{Local-\gls{SDS} specific \glspl{SDS}}
A single \gls{SDS} on a single device can be accessed using the \CI{shareShare}
-function. This function focusses the real big \gls{SDS} on a single share and
-uses the \CI{mapReadWrite} functions to serve the correct part of the
+function. This function focusses the real big \gls{SDS} on a single \gls{SDS}
+and uses the \CI{mapReadWrite} functions to serve the correct part of the
information.
\begin{lstlisting}[caption={Local \gls{SDS}}]
interface shows the list of example \glspl{Task} that are present in the
system. When clicking a \gls{Task}, a dialog opens in which a device can be
selected 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.
+variables. All example \gls{mTask}-\glspl{Task} are of the type \CI{Task (Main
+(ByteCode () Stmt))} and can thus ask for user input first if needed for
+parameterized \gls{mTask}-\glspl{Task}. 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.
\begin{figure}[H]
\centering
\end{figure}
\section[Lifting mTasks to iTasks-Tasks]%
- {Lifting \glspl{mTask} to \gls{iTasks}-\glspl{Task}}
+ {Lifting \gls{mTask}-\glspl{Task} to \gls{iTasks}-\glspl{Task}}
If the user does not want to know where and when a \gls{mTask} is actually
executed and is just interested in the results it can lift the \gls{mTask} to
an \gls{iTasks}-\glspl{Task}. The function is called with a name, \gls{mTask},
repositories / msc-thesis1617.git / blobdiff