+For a type to be suitable, it must have instances for a collection of generic
+functions that is captured in the class \CI{iTask}. Basic types have
+specialization instances for these functions and show an interface accordingly.
+Derived interfaces can be modified with decoration operators or specializations
+can be created.
+
+\section{Combinators}
+\Glspl{Task} can be combined using so called \gls{Task}-combinators.
+Combinators describe relations between \glspl{Task}. There are only two basic
+types of combinators; namely parallel and sequence. All other combinators are
+derived from the basic combinators. Type signatures of simplified versions of
+the basic combinators and their derivations are given in
+Listing~\ref{lst:combinators}
+
+\begin{lstlisting}[%
+ caption={\Gls{Task}-combinators},label={lst:combinators}]
+//Step combinator
+(>>=) infixl 1 :: (Task a) (a -> Task b) -> Task b | iTask a & iTask b
+(>>*) infixl 1 :: (Task a) [TaskCont a (Task b)] -> Task b | iTask a & iTask b
+:: TaskCont a b
+ = OnValue ((TaskValue a) -> Maybe b)
+ | OnAction Action ((TaskValue a) -> Maybe b)
+ | E.e: OnException (e -> b) & iTask e
+ | OnAllExceptions (String -> b)
+:: Action = Action String
+
+//Parallel combinators
+(-||-) infixr 3 :: (Task a) (Task a) -> Task a | iTask a
+(||-) infixr 3 :: (Task a) (Task b) -> Task b | iTask a & iTask b
+(-||) infixl 3 :: (Task a) (Task b) -> Task a | iTask a & iTask b
+(-&&-) infixr 4 :: (Task a) (Task b) -> Task (a,b) | iTask a & iTask b
+\end{lstlisting}
+
+\paragraph{Sequence:}
+The implementation for the sequence combinator is called the
+\CI{step} (\CI{>>*}). This combinator runs the left-hand \gls{Task} and
+starts the right-hand side when a certain predicate holds. Predicates
+can be propositions about the \CI{TaskValue}, user actions from within
+the web browser or a thrown exception. The familiar
+bind-combinator is an example of a sequence combinator. This combinator
+runs the left-hand side and continues to the right-hand \gls{Task} if
+there is an \CI{UnStable} value and the user presses continue or when
+the value is \CI{Stable}. The combinator could have been implemented
+as follows:
+\begin{lstlisting}[language=Clean]
+(>>=) infixl 1 :: (Task a) (a -> (Task b)) -> (Task b) | iTask a & iTask b
+(>>=) ta f = ta >>* [OnAction "Continue" onValue, OnValue onStable]
+ where
+ onValue (Value a _) = Just (f a)
+ onValue _ = Nothing
+
+ onStable (Value a True) = Just (f a)
+ onStable _ = Nothing
+\end{lstlisting}
+
+\paragraph{Parallel:}
+The parallel combinator allows for concurrent \glspl{Task}. The
+\glspl{Task} combined with these operators will appear at the same time
+in the web browser of the user and the results are combined as the type
+dictates. All parallel combinators used are derived from the basic parallel
+combinator that is very complex and only used internally.
+
+\section{Shared Data Sources}
+\Glspl{SDS} are an abstraction over resources that are available in the world
+or in the \gls{iTasks} system. The shared data can be a file on disk, the
+system time, a random integer or just some data stored in memory. The actual
+\gls{SDS} is just a record containing functions on how to read and write the
+source. In these functions the \CI{*IWorld} --- which in turn contains the real
+\CI{*World} --- is available. Accessing the outside world is required for
+interacting with it and thus the functions can access files on disk, raw
+memory, other \glspl{SDS} and hardware.
+
+The basic operations for \glspl{SDS} are get, set and update. The signatures
+for these functions are shown in Listing~\ref{lst:shares}. By default, all
+\glspl{SDS} are files containing a \gls{JSON} encoded version of the object and
+thus are persistent between restarts of the program. Library functions for
+shares residing in memory are available as well. The three main operations on
+shares are atomic in the sense that during reading no other \glspl{Task} are
+executed. The system provides useful functions to transform, map and combine
+\glspl{SDS} using combinators. The system also provides functionality to
+inspect the value of a \gls{SDS} and act upon a change. \Glspl{Task} waiting on
+a \gls{SDS} to change are notified when needed. This results in low resource
+usage because \glspl{Task} are never constantly inspecting \gls{SDS} values but
+are notified.
+
+\begin{lstlisting}[%
+ label={lst:shares},caption={\Gls{SDS} functions}]
+:: RWShared p r w = ...
+:: ReadWriteShared r w :== RWShared () r w
+:: ROShared p r :== RWShared p () r
+:: ReadOnlyShared r :== ROShared () r