.

[msc-thesis1617.git] / arch.itasks.tex

diff --git a/arch.itasks.tex b/arch.itasks.tex
index f7fc915..7f9ac60 100644 (file)
--- a/arch.itasks.tex
+++ b/arch.itasks.tex
@@ -5,6 +5,31 @@ 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.
 
+\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
@@ -29,7 +54,7 @@ types.
                , deviceResource :: MTaskResource
                , deviceSpec     :: Maybe MTaskDeviceSpec
                , deviceShares   :: [MTaskShare]
-       }
+               }
 
 channels :: MTaskDevice -> Shared Channels
 
@@ -59,17 +84,16 @@ is given in Listing~\ref{lst:mtaskdevice}. The definitions of the message
 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