Mercurial > docs > diploma
comparison thesis/tex/4-MasqmailsFuture.tex @ 404:f0fa40e30dfb
finally decided to not cover smtp submission ... sadly :-(
| author | meillo@marmaro.de |
|---|---|
| date | Sun, 08 Feb 2009 23:15:35 +0100 |
| parents | e57129f57faa |
| children | a3d9a63defa7 |
comparison
equal
deleted
inserted
replaced
| 403:b357dfc509b5 | 404:f0fa40e30dfb |
|---|---|
| 73 \label{fig:mta-channels} | 73 \label{fig:mta-channels} |
| 74 \end{figure} | 74 \end{figure} |
| 75 | 75 |
| 76 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}. | 76 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}. |
| 77 | 77 |
| 78 %fixme: write about submission (port 587) | |
| 79 | 78 |
| 80 | 79 |
| 81 | 80 |
| 82 | 81 |
| 83 \paragraph{\RF\,2: Mail queuing} | 82 \paragraph{\RF\,2: Mail queuing} |
| 398 \paragraph{\RF\,1: In/out channels} | 397 \paragraph{\RF\,1: In/out channels} |
| 399 \index{incoming channels} | 398 \index{incoming channels} |
| 400 \index{outgoing channels} | 399 \index{outgoing channels} |
| 401 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. | 400 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. |
| 402 | 401 |
| 403 %fixme: << smtp submission >> | |
| 404 | |
| 405 \paragraph{\RF\,2: Queuing} | 402 \paragraph{\RF\,2: Queuing} |
| 406 \index{mail queue} | 403 \index{mail queue} |
| 407 One single mail queue is used in \masqmail. It satisfies all current requirements. | 404 One single mail queue is used in \masqmail. It satisfies all current requirements. |
| 408 | 405 |
| 409 \paragraph{\RF\,3: Header sanitizing} | 406 \paragraph{\RF\,3: Header sanitizing} |
| 797 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, here. The long-time view is the following time. | 794 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, here. The long-time view is the following time. |
| 798 | 795 |
| 799 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. | 796 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. |
| 800 \index{existing code} | 797 \index{existing code} |
| 801 | 798 |
| 802 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. | 799 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. |
| 803 | 800 |
| 804 %fixme: define exactly, be clear: what does ``break even'' here mean | 801 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. |
| 802 | |
| 805 | 803 |
| 806 | 804 |
| 807 | 805 |
| 808 \subsubsection*{The problem with ``good enough''} | 806 \subsubsection*{The problem with ``good enough''} |
| 809 \index{good enough} | 807 \index{good enough} |