1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sun Feb 08 23:13:12 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sun Feb 08 23:15:35 2009 +0100
     1.3 @@ -75,7 +75,6 @@
     1.4  
     1.5  An overview on incoming and outgoing channels which are required for an \MTA, gives figure~\ref{fig:mta-channels}. The reader may want to compare this diagram with \masqmail's incoming and outgoing channels, which are depicted in figure~\ref{fig:masqmail-channels} on page~\pageref{fig:masqmail-channels}.
     1.6  
     1.7 -%fixme: write about submission (port 587)
     1.8  
     1.9  
    1.10  
    1.11 @@ -400,8 +399,6 @@
    1.12  \index{outgoing channels}
    1.13  The incoming and outgoing channels that \masqmail\ already has (depicted in figure~\ref{fig:masqmail-channels} on page \pageref{fig:masqmail-channels}) are the ones required for an \MTA{}s at the moment. Currently, support for other protocols seems not to be necessary, although new protocols and mailing concepts are likely to appear (see section~\ref{sec:email-trends}). As other protocols are not required today, \masqmail\ is regarded to fulfill \RF\,1. Without any support in \masqmail\ for adding further protocols, the best strategy is to delaying such work until the functionality is essential, anyway.
    1.14  
    1.15 -%fixme: << smtp submission >>
    1.16 -
    1.17  \paragraph{\RF\,2: Queuing}
    1.18  \index{mail queue}
    1.19  One single mail queue is used in \masqmail. It satisfies all current requirements.
    1.20 @@ -799,9 +796,10 @@
    1.21  In the short-time view, the effort for improving the existing code is much smaller than the effort for a new design plus improvements. But to have similar quality properties at the end of the short-time frame, a version that is based on current code will probably require nearly as much effort as a new designed version will take. For all further development afterwards, the new design will scale well while the old code will require exponential more work.
    1.22  \index{existing code}
    1.23  
    1.24 -In the long-time view, a restructuring for modularity is necessary anyway. The question is, when it should be done: Right at the start in a new design, or later as restructuring work.
    1.25 +The Break Even is the point in time when a new design is better than improvements of the old code for the first time. From this point on, the new design will be the better solution.
    1.26  
    1.27 -%fixme: define exactly, be clear: what does ``break even'' here mean
    1.28 +In the long-time view, a restructuring for modularity is necessary anyway to keep the maintaining effort bearable. The question is, when the restructuring should be done: Right at the start in a new design, or later as restructuring work.
    1.29 +
    1.30  
    1.31  
    1.32