provides functionality to list \glspl{SDS}, add and remove \glspl{Task},
administrate devices and view the state of the system.
+\subsection{Device Specification}
+The server stores a description for every device available in a record type.
+From the macro settings in the interface file, a profile is created that
+describes the specification of the device. When the connection between the
+server and a client is established, the server will send a request for
+specification. The client serializes its specification and send it to the
+server so that the server knows what the client is capable of. The exact
+specification is shown in Listing~\ref{lst:devicespec} and stores the
+peripheral availability, the memory available for storing \glspl{Task} and
+\glspl{SDS} and the size of the stack. Not all peripheral flags are shown for
+brevity. The encoding for this interface
+
+\begin{lstlisting}[label={lst:devicespec},
+ caption={Device specification for \gls{mTask}-\glspl{Task}}]
+:: MTaskDeviceSpec =
+ { haveLed :: Bool
+ , haveLCD :: Bool
+ , have...
+ , bytesMemory :: Int
+ , stackSize :: Int
+ , aPins :: Int
+ , dPins :: Int
+ }
+\end{lstlisting}
+
\subsection{Device Storage}
Everything that a device encompasses is stored in the \CI{MTaskDevice} record
type. This includes management for the \glspl{SDS} and \glspl{Task} stored on
, deviceResource :: MTaskResource
, deviceSpec :: Maybe MTaskDeviceSpec
, deviceShares :: [MTaskShare]
- }
+ }
channels :: MTaskDevice -> Shared Channels
format are explained in the following section.
\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 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
-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 level of
-granularity.
+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 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 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 level of granularity.
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