1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sun Jan 18 11:54:04 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sun Jan 18 13:08:32 2009 +0100
     1.3 @@ -587,7 +587,7 @@
     1.4  
     1.5  
     1.6  
     1.7 -\subsubsection*{The break even}
     1.8 +\subsubsection*{Break Even}
     1.9  
    1.10  It is important to keep the time dimension in mind. This includes the  separation into a short-time and a long-time view. The short-time view shall cover between two and four years. The long-time view is the following time. % fixme: find sources!
    1.11  
    1.12 @@ -595,6 +595,7 @@
    1.13  
    1.14  In the long-time view, a restructuring for modularity is necessary anyway. The question is, when to do it: Right at the start in a new design, or later in some restructuring.
    1.15  
    1.16 +%fixme: define exactly, be clear: what does break even here mean
    1.17  
    1.18  
    1.19  
    1.20 @@ -612,7 +613,7 @@
    1.21  
    1.22  
    1.23  
    1.24 -\subsubsection*{Bonus: Good software, good feelings}
    1.25 +\subsubsection*{Good software, good feelings}
    1.26  
    1.27  One last argument shall be added. It is more common for Free Software but can be seen in non-free software too.
    1.28  
    1.29 @@ -631,40 +632,45 @@
    1.30  
    1.31  \section{Result}
    1.32  
    1.33 +This chapter identified the requirements and the outstanding work to achieve them. Their importance and the required work on them lead to a focus ranking amoung the requirements, which resulted in a list of tasks to do. Afterwards possible development strategies to control the work process were compared and discussed.
    1.34  
    1.35 -what stands against the new design? 
    1.36 -- dev time/effort
    1.37 -- risk of failure
    1.38 -- time delay
    1.39 +Strategy 3 (A new design) is slightly prefered over the combination of strategy 1 (Improve existing code) and 2 (Add wrappers and interposition filters) in regard of the requirements.
    1.40  
    1.41 -
    1.42 -A program's structure is primary its architecture. Which is the most influencing design decision, and has the greatest impact on the program's future capabilities. The architecture defines what the program can do, and how it can be used. If the architecture does not fit to the requirements, development will reach a dead end \dots\ further work then will make everything worse. The only good solution then is to change the architecture, which, sadly but most likely, means a redesign from scratch.
    1.43 -
    1.44 -The most needed features---authentication and encryption---can be added to the current code base with changes in only few parts of the source. These changes should be made soon. Archiving of mail is another feature to add then. More complete logging coverage, reporting of unsafe environment, and fixing high risk security flaws are quality improvements to do. All this work should be done on basis of the current code.
    1.45 -
    1.46 -
    1.47 -
    1.48 +The discussion afterwards did generally support the new design strategy. But some arguments stand against it. These are:
    1.49  
    1.50  \begin{enumerate}
    1.51 -\item
    1.52 -Stick to the old architecture and try to add features as possible. This approach needs less effort to be spent, because a working code is already present. Further development is only adding small increments to a exiting code base. But the further development goes, the larger is the work needed to add more functionality, and the more bugs will appear, caused by the increasing complexity. Quality of the software will decrease, because lacking of clear internal structure encourages further work to be quick fixes rather than good solutions.
    1.53 -
    1.54 -\item
    1.55 -The way of designing \masqmail\ from scratch and rebuilding it. A lot of time and work is required to do this. Additionally, a new design from scratch introduces new risks: Is the design really better? Was thought of everything? Will there come problems not foreseeable now? Starting from scratch also means a step back. Against these disadvantages stands the gain from the new design: Further development will be easier and probably faster, overall quality will be better and easier to keep up, and dead ends for further development are better avoidable.
    1.56 +\item The development time and effort
    1.57 +\item The time delay until new features can be added
    1.58 +\item The risks for failure
    1.59  \end{enumerate}
    1.60  
    1.61 +The first two arguments are only relevant for the short-time view, because both will become \emph{support arguments} for the new design, once the Break Even point is reached.
    1.62  
    1.63 +The third argument, the risks, remain. There are risk in every investion. Taking no risks means remaining the same, means drifting towards a dead end in a world that does change.
    1.64  
    1.65  
    1.66 +With respect to the current situation, the suggested further development plan for \masqmail\ is splitted into a short-time plan and a long-time plan:
    1.67  
    1.68 -The suggested further development plan for \masqmail\ is:
    1.69  \begin{enumerate}
    1.70 -\item The short time goal: Add the most needed features, being authentication and encryption, to the current code base. \item The long time goal: Design a new architecture that satisfies the requirements identified, especially the quality requirements. The implementation of this design shall then, after being usable and throughout tested, supersede the old \masqmail.
    1.71 +\item The short-time plan: Add the most needed features, being encryption, authentication, and security wrappers, to the current code base.
    1.72 +\item The long-time plan: Design a new architecture that satisfies the modern requirements especially the quality requirements.
    1.73  \end{enumerate}
    1.74  
    1.75 -This plan is similar to the change from \sendmail\ to \name{sendmail X}/\name{MeTA1}, except the \sendmail\ change was much too late.
    1.76 +The background thought is to first do the most needed stuff on the existing code to keep %fixme: erhalten
    1.77 +it usable. This satisfies the urgent needs and removes the time pressure from the development of the new design. After this is done, a new designed \masqmail\ should be developed from scratch. This is the work for the future. It shall, after it is usable and throughout tested, supersede the old \masqmail.
    1.78  
    1.79 -The following chapter is about the work on the current code base, to reach the short time goals. The chapter afterwards then introduces a new, modern design for future versions of \masqmail.
    1.80 +The basic idea is, regularly developing a new design from scratch while the current version is still in use and gets repaired. Hence a modern design will inherit an old one in regular intervals. This is a very future-proove concept that combines the best of both worlds. The price to pay is only the increased work which gets covered %fixme: uebernommen
    1.81 +by volunteers that \emph{want} to do it.
    1.82  
    1.83  
    1.84 -%The plan is to first do the most needed stuff on the old design to make it still usable; then design a new version from scratch, for the future.
    1.85 +
    1.86 +%fixme: move that sentence to the beginning of the next chapter?
    1.87 +The following chapter describes approaches and techniques for the work on the current code base, and it introduces ideas and plans for a new, modern \MTA\ design the next generation of \masqmail.
    1.88 +
    1.89 +
    1.90 +
    1.91 +
    1.92 +%A program's structure is primary its architecture. Which is the most influencing design decision, and has the greatest impact on the program's future capabilities. The architecture defines what the program can do, and how it can be used. If the architecture does not fit to the requirements, development will reach a dead end \dots\ further work then will make everything worse. The only good solution then is to change the architecture, which, sadly but most likely, means a redesign from scratch.
    1.93 +
    1.94 +%This plan is similar to the change from \sendmail\ to \name{sendmail X}/\name{MeTA1}, except the \sendmail\ change was much too late.
    1.95 +