1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sun Jan 11 14:07:48 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sun Jan 11 15:38:39 2009 +0100
     1.3 @@ -203,9 +203,11 @@
     1.4  
     1.5  
     1.6  
     1.7 -\subsection{Architectural requirements}
     1.8 +\subsection{Thoughts about architecture}
     1.9  \label{sec:discussion-mta-arch}
    1.10  
    1.11 +%todo: what's this section to do with requirements?
    1.12 +
    1.13  \masqmail's current architecture is monolithic like \sendmail's and \exim's. But more than the other two, is it one block of interweaved code. \exim\ has a highly structured code with many internal interfaces, a good example is the one for authentication ``modules''. %fixme: add ref
    1.14  \sendmail\ provides now, with its \name{milter} interface, standardized connection channels to external modules.
    1.15  \masqmail\ has none of them; it is what \sendmail\ was in the beginning: a single large block.
    1.16 @@ -235,10 +237,9 @@
    1.17  
    1.18  Modularity is also needed to satisfy modern \MTA\ requirements, in providing a clear interface to add functionality without increasing the overall complexity much.
    1.19  
    1.20 -Modularity is a goal that, if achieved, has positive influence on other important properties like security, testability, extendability, maintainability, and not least simplicity. These quality properties then, on their part, make achieving the functional requirements easier.
    1.21 +Modularity is no direct requirement, but a goal that has positive influence on important requirements like security, testability, extendability, maintainability, and not least simplicity. These quality properties then, on their part, make achieving the functional requirements easier.
    1.22  
    1.23 -Hence, aspiration for modularity, by compartmentalization, leads to improvement of the overall quality of the software. It is an architectural requirement for a secure and modern \MTA.
    1.24 -
    1.25 +Hence, aspiration for modularity, by compartmentalization, improves the overall quality and function of the software. It can be seen as an architectural requirement for a secure and modern \MTA.
    1.26  
    1.27  
    1.28  
    1.29 @@ -320,6 +321,11 @@
    1.30  
    1.31  
    1.32  
    1.33 +\paragraph{Modularity}
    1.34 +Modularity---the important architectural goal---is currently not existent in \masqmail's code. The whole source is interweaved.
    1.35 +
    1.36 +
    1.37 +
    1.38  
    1.39  
    1.40  
    1.41 @@ -332,7 +338,7 @@
    1.42  		\input{input/requirements.tex}
    1.43  	\end{center}
    1.44  	\caption{Importance of and pending work for requirements}
    1.45 -	\label{tab:requirents}
    1.46 +	\label{tab:requirements}
    1.47  \end{table}
    1.48  
    1.49  The importance is ranked from `-{}-' (not important) to `++' (very important). The pending work is ranked from `-{}-' (nothing) to `++' (very much). Large work tasks with high importance need to receive much attention, they are in focus. In contrast should small low importance work receive few attention. Here the attention/focus a task should get is calculated by summing up the importance and the pending work with equal weight. Normally, tasks with high focus are the ones of high priority and should be done first.
    1.50 @@ -357,6 +363,7 @@
    1.51  
    1.52  \subsubsection*{\TODO4: Reliability (\RG2)}
    1.53  Reliability is also to improve. It is a key quality property for an \MTA, and not good enough in \masqmail. Reliability is strong related to the queue, thus improvements there are favorable. Applying ideas of \name{crash-only software} \cite{candea03} will be a good step. \person{Candea} and \person{Fox} see in killing the process the best way to stop a running program. Doing so inevitably demands for good reliability of the queue, and the startup inevitably demands for good recovery. The critical situations for reliability are nothing special anymore, they are common. Hence they are regulary tested and will definately work.
    1.54 +% persistence, database
    1.55  
    1.56  \subsubsection*{\TODO5: Spam handling (\RF8)}
    1.57  As authentication can be a guard against spam, filter facilities have lower priority. But basic spam filtering and interfaces for external tools should be implemented in future.
    1.58 @@ -377,8 +384,10 @@
    1.59  Performance is a property that is nice to have. But as performance improvements are in contrast to many other quality properties (reliability, maintainability, usability, capability \cite[page~5]{kan03}), jeopardizing these to gain some more performance should not be done. \person{Kernighan} and \person{Pike} state clear: ``[T]he first principle of optimization is \emph{don't}.''\cite[page~165]{kernighan99}. \masqmail\ is not a program to be used on large servers, but on small devices. Thus important for \masqmail\ could be energy and heat saving, maybe also system resources, but not performance. Anyway, simplicity and clearness are of higher value.
    1.60  
    1.61  Portability among the various flavors of \unix\ systems is a goal, because these systems are the ones \MTA{}s run on usually. Portability problems with non-\unix\ platforms are primary expected to come from file systems lacking required features. But no special care should be taken here.
    1.62 +% unix fs on windows
    1.63  
    1.64  Configuration could be eased more, by providing configuration generators to be able to use \masqmail\ right ``out of the box'' after running one of several configuration scripts for common setups. This would improve \masqmail's usability for not technical educated people.
    1.65 +% masqmail as portable app?
    1.66  
    1.67  
    1.68