1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Mon Dec 29 21:43:52 2008 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Tue Dec 30 13:22:21 2008 +0100
     1.3 @@ -51,35 +51,54 @@
     1.4  
     1.5  \subsection{General requirements}
     1.6  
     1.7 -The following list of general requirements applies not only to \masqmail, but to all kinds of programs in similar environment doing similar jobs with the same intention. These requirements can be covered by the term ``quality''.
     1.8 -%fixme: add cites
     1.9 +Here follows a list of quality requirements for \masqmail, or other kinds of programs in similar environment and with similar jobs. These requirements specify the non-functional properties of the software, thus they are also called \name{non-functional requirements}. The list is based on \person{Hafiz} \cite[page~2]{hafiz05}, with insperation from \person{Spinellis} \cite[page~6]{spinellis06}.
    1.10  %fixme: refer to ch01 and ch02
    1.11 -General requirements specify the non-functional properties of the software, thus they are also called \name{non-functional requirements}.
    1.12  
    1.13  
    1.14  \subsubsection*{Security}
    1.15 -\MTA{}s are critical points for computer security, as they are accessable from external networks. They must be secured with high effort. Properties like high priviledge level, work load influenced from extern, work on unsafe data, and demand for reliability, increase the security needed. Unsecure and unreliable \mta{}s are of no value. \masqmail\ needs to b e secure enough for its target field of operation.
    1.16 +\MTA{}s are critical points for computer security, as they are accessable from external networks. They must be secured with high effort. Properties like high priviledge level, work load influenced from extern, work on unsafe data, and demand for reliability, increase the security needed. \masqmail\ needs to be secure enough for its target field of operation.
    1.17  
    1.18  
    1.19  \subsubsection*{Reliability}
    1.20 -<< crash only software >>
    1.21 +Reliability is the second essential quality property for an \MTA. Mail, for which the \MTA\ took responsibility, must never get lost. The \MTA\ must not be the cause of any mail loss, no matter what happens. Unreliable \mta{}s are of no value.
    1.22  
    1.23 -<< dont lose mail >>
    1.24 +
    1.25 +\subsubsection*{Robustness}
    1.26 +Being robust means handling errors properly. Small errors may get tolerated, large errors may kill a process, to get restarted afterwards. Log messages should be written in every case. Robust software does not need a special environment, it creates the right environment itself. \person{Raymond}'s \name{Rule of Robustness} and his \name{Rule of Repair} are good descriptions.\cite[page~18--21]{raymond03}
    1.27  
    1.28  
    1.29  \subsubsection*{Extendability}
    1.30  Modern needs like large messages demand for more efficient mail transport through the net. Aswell is a final solution needed to defeat the spam problem. New mail transport protocols seem to be the only good solutions for both problems. They also can improve reliability, authentication, and verification issues. \masqmail\ should be able to support new mail transfer protocols as they appear and are used.
    1.31  %fixme: like old sendmail, but not too much like it
    1.32  
    1.33 +\subsubsection*{Maintainability}
    1.34 +Maintaining software takes much time and effort. \person{Spinellis} measures ``40\% to 70\% of the effort that goes into a software system is expended after the system is written first time.''\cite[page~1]{spinellis03} This is maintaining work. Hence making software good to maintain is effort that will become invalueable afterwards.
    1.35  
    1.36 -\subsubsection*{Ressource friendly software}
    1.37 +
    1.38 +\subsubsection*{Testability}
    1.39 +Good testability make maintainance easier, because functionality is directly verifiable when changes are done, thus removing the uncertaintay. Modularized software makes testing easier, because parts can be testet without external influences.
    1.40 +
    1.41 +
    1.42 +\subsubsection*{Performance}
    1.43 +Also called ``efficiency''. Software requiring few time and few resources is nice. But as performance improvements are in contrast to many other quality poperties (reliability, maintainability, usability, capability \cite[page~5]{kan03}), japardizing them 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{kernighan99}
    1.44 +
    1.45  The merge of communication hardware and the move of email services from providers to homes, demands smaller and more resource-friendly software. The amount of mail will be lower, even if much more mail will be sent. More important will be the energy consumption and heat emission. These topics increased in relevance during the past years and they are expected to become more central. \masqmail\ is not a program to be used on large servers, but to be used on small devices. Thus focusing on energy and heat, not on performance, is the direction to go.
    1.46  
    1.47  
    1.48 -\subsubsection*{Easy configuration}
    1.49 -Having \mta{}s on many home servers and clients, requires easy and standardized configuration. The common setups should be configurable with single actions by the user. Complex configuration should be possible, but focused must be the most common form of configuration: choosing one of several standard setups.
    1.50 +\subsubsection*{Availability}
    1.51 +Availability is important for server programs. They must stay operational, even when bad guys run \name{denial of service} attacks.
    1.52  
    1.53  
    1.54 +\subsubsection*{Portability}
    1.55 +Not to forget is portability. It can be accieved by using standard features of the programming language and common libraries. Basic rules for portable code are defined by \person{Kerighan} and \person{Pike} \cite{kernighan99}.
    1.56 +
    1.57 +Focusing on \unix\ systems seems to be okay, but being portable between different flavors of them is important. Also should the \masqmail\ be independent of the underlying file system.
    1.58 +
    1.59 +
    1.60 +\subsubsection*{Usability}
    1.61 +Usability, not mentioned by \person{Hafiz} 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 roughly equivilent substitutes with better usability exist, the user will switch to one of them.
    1.62 +
    1.63 +Usability here means easy to set up and configure, too. Having \mta{}s on many home servers and clients, requires easy and standardized configuration. The common setups should be configurable with single actions by the user. Complex configuration should be possible, but focused must be the most common form of configuration: choosing one of several standard setups.
    1.64  
    1.65  
    1.66  
    1.67 @@ -224,7 +243,7 @@
    1.68  
    1.69  
    1.70  %fixme: write about non-functional requirements
    1.71 -
    1.72 + Making \masqmail\ a \name{crash-only software}\cite{candea03} would be a step to make it more robust.
    1.73  
    1.74  
    1.75  \subsubsection*{Missing parts}