docs/diploma: thesis/tex/4-MasqmailsFuture.tex comparison

comparison thesis/tex/4-MasqmailsFuture.tex @ 242:aff94e950f39

minor stuff in ch04

author	meillo@marmaro.de
date	Sun, 11 Jan 2009 15:38:39 +0100
parents	2c56f26758eb
children	724cc6057105

comparison

equal deleted inserted replaced

-:2c56f26758eb
+:aff94e950f39
 Usability, not mentioned by \person{Hafiz} (he focuses on architecture) but by \person{Spinellis} and \person{Kan}, is a property very important from the user's point of view. Software with bad usability is rarely used, no matter how good it is. If substitutes with better usability exist, the user will switch to one of them. Here, usability includes setting up and configuring; and the term ``users'' includes administrators. Having \mta{}s on home servers and workstations requires easy and standardized configuration. The common setups should be configurable with little action by the user. Complex configuration should be possible, but focused must be the most common form of configuration: choosing one of several common setups.
-\subsection{Architectural requirements}
+\subsection{Thoughts about architecture}
 \label{sec:discussion-mta-arch}
+%todo: what's this section to do with requirements?
 \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
 \sendmail\ provides now, with its \name{milter} interface, standardized connection channels to external modules.
 \masqmail\ has none of them; it is what \sendmail\ was in the beginning: a single large block.
 \end{quote}
 Equal does \person{Dent} see the situation for \postfix: ``The modular architecture of Postfix forms the basis for much of its security.'' \cite[page 7]{dent04}
 Modularity is also needed to satisfy modern \MTA\ requirements, in providing a clear interface to add functionality without increasing the overall complexity much.
-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.
+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.
-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.
+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.
 \section{Fulfilled requirements}
 \paragraph{\RG10: Usability}
 The usability, from the administrator's point of view, is very good. \masqmail\ was developed to suite a specific, limited job---its configuration does perfect match. The user's view does not reach to the \MTA, as it is hidden behind the \name{mail user agent}.
+\paragraph{Modularity}
+Modularity---the important architectural goal---is currently not existent in \masqmail's code. The whole source is interweaved.
 \section{Work to do}
 \begin{table}
 	\begin{center}
 		\input{input/requirements.tex}
 	\end{center}
 	\caption{Importance of and pending work for requirements}
-	\label{tab:requirents}
+	\label{tab:requirements}
 \end{table}
 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.
 The functional requirements that receive highest attention are \RF6: authentication, \RF7: encryption, and \RF8: spam handling. Of the non-functional requirements, \RG1: security, \RG2: reliability, and \RG4: Extendability, rank highest.
 Improving security is an important thing to do. Especially, \masqmail's security should be tested throughout to get a definitive view how good it really is and where the weak spots are.
 \subsubsection*{\TODO4: Reliability (\RG2)}
 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.
+% persistence, database
 \subsubsection*{\TODO5: Spam handling (\RF8)}
 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.
 Archiving again is preferred to be implemented soon. It does not require much work, but enables all kinds of statistical analysis.
 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.
 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.
+% unix fs on windows
 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.
+% masqmail as portable app?

Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 242:aff94e950f39