1.1 --- a/thesis/tex/3-MailTransferAgents.tex	Mon Jan 12 12:52:36 2009 +0100
     1.2 +++ b/thesis/tex/3-MailTransferAgents.tex	Mon Jan 12 12:53:03 2009 +0100
     1.3 @@ -1,4 +1,5 @@
     1.4  \chapter{Mail transfer agents}
     1.5 +\label{chap:mail-transfer-agents}
     1.6  
     1.7  After having analyzed the market for electronic mail and identified upcoming trends, in the last chapter; this chapter takes a look at \mta{}s---the intelligent nodes and thus the most important parts of the email infrastructure. The \MTA{}s will be grouped by similarities first. Then the four most popular \freesw\ \mta{}s, will be presented to the reader in a short overview and with the most important facts. At the end of this chapter these programs will be compared.
     1.8  

     2.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Mon Jan 12 12:52:36 2009 +0100
     2.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Mon Jan 12 12:53:03 2009 +0100
     2.3 @@ -372,6 +372,9 @@
     2.4  \subsubsection*{\TODO6: Extendability (\RG4)}
     2.5  Extendability does suffer from the monolithic architecture and is nearly impossible to improve without changing the programs structure. This property can hardly be retrofitted into software. Extendability is expected become important in the future as new protocols need to be supported.
     2.6  
     2.7 +\masqmail\ lacks an interface to plug in modules with additional functionality. There exists no add-on or module system. The code is only separated by function to the various source files. Some functional parts can be included or excluded by defining symbols at compile time. Adding maildir support, means giving the option \verb+--enable-maildir+ to the \path{configure} call. This preserves the concerning code to get removed by the preprocessor. Unfortunately the \verb+#ifdef+s are scattered through all the source, leading to a code that is hard to read.
     2.8 +%fixme: refer to ifdef-considered-harmful ?
     2.9 +
    2.10  
    2.11  
    2.12  
    2.13 @@ -455,6 +458,16 @@
    2.14  
    2.15  
    2.16  
    2.17 +---
    2.18 +
    2.19 +on venema: ``there'll be no second postfix'':
    2.20 +
    2.21 +Yes there will be one, when postfix becomes obsolete, and this day will come as requirements change. See sendmail for example: it had nearly the whole market ... and now it's dying. sendmail once also thought it would be the number 1, forever.
    2.22 +
    2.23 +cf. Tanenbaum vs. Linux: It was too early. Linux' time has not ended, but it will some day.
    2.24 +
    2.25 +anyway, masqmail is not intended to become a second postfix. It's more inteded to become a second qmail, but with a differend target field.
    2.26 +
    2.27  
    2.28  ---
    2.29  
    2.30 @@ -488,10 +501,37 @@
    2.31  All this leads to the wish of a rewrite of \masqmail, using a modern, modular architecture, \emph{if} further features need to be added---features that require changes in \masqmail's structure. But a rewrite is also mandatory, if \masqmail\ should become a modern \MTA, with good quality properties.
    2.32  
    2.33  
    2.34 +\subsubsection*{Further reasons for a new design}
    2.35  
    2.36 +impressing  simplicity of qmail: only about 1000 SLOC per file (= about one module). It's obvious what it does. cf. suckless.org
    2.37  
    2.38  
    2.39 +do not try to safe obsolete stuff. This will not work (see sendmail).
    2.40  
    2.41 +It is often done in commercial software, when it's about making money. Free software with volunteer programmers in contrast care about good software..
    2.42 +
    2.43 +If the design is bad, one should never hesitate to abandonne obsolete stuff and build it from scratch. (cf. makefiles and tab).
    2.44 +
    2.45 +But making a cut is hard, as it is still ``good enough''.
    2.46 +
    2.47 +
    2.48 +---
    2.49 +
    2.50 +repair strategies is only useful in the short time view and for hard times. but if the future is bright, one must invest. here it means redesigning to build up a more modern product. cf. ch02: the future is bright!
    2.51 +
    2.52 +Masqmail should have been redesigned in 2002 or so, when the old design was still quite suitable ... it already delayed too long.
    2.53 +
    2.54 +Clinging to much to existing code will be no help, it is an indicator for fear. Having the courage to through bad code away to make it better, shows the view forward.
    2.55 +
    2.56 +---
    2.57 +
    2.58 +repairing leaves a worse feeling. Free Software ``sells'' if it has a good userbase. Although qmail is somehow outdated and its author has released no new version since about 10 years, qmail has a very strong userbase and community.
    2.59 +
    2.60 +Good design, concepts and philosophy gives users good feelings and faith for the software. They become interested in using it and to contribute.
    2.61 +
    2.62 +
    2.63 +
    2.64 +The goal is good software. The wish to do good work is the motivation volunteers have. Work plans that lead to a good product will motivate volunteers to help with it. Hence more helpers may make the 2,5 man years for the new design, even become less absolute time than, few helping people that try to improve the existing code.
    2.65  
    2.66  
    2.67