1.1 --- a/thesis/tex/2-MarketAnalysis.tex	Wed Dec 10 08:32:12 2008 +0100
     1.2 +++ b/thesis/tex/2-MarketAnalysis.tex	Wed Dec 10 16:48:41 2008 +0100
     1.3 @@ -21,7 +21,7 @@
     1.4  
     1.5  Another possible separation is to distinguished written and recorded information. Recorded information, like audio or video data, is accessible only in a linear way by spooling and replay. Written information, on the other hand, can be accessed in arbitrary sequence, detail and speed.
     1.6  
     1.7 -Lenke and Schmitz \cite{lenke95} use the same criteria to classify \emph{new media}. %fixme: is this term common?
     1.8 +\person{Lenke} and \person{Schmitz} \cite{lenke95} use the same criteria to classify \emph{new media}. %fixme: is this term common?
     1.9  They additionally divide into local and remote communication---the latter is presumed here---and by the number of communication participants. As communication technologies for n:m communication (like chat rooms) are usable for 1:1 too (private chat), and ones for 1:1 (email) are usable for n:m (mailing lists), a classification by participant structures is omitted here.
    1.10  
    1.11  Figure \ref{fig:comm-classification} shows a classification of communication technologies sorted by the properties synchronous/asynchronous and written/recorded. Email and \NAME{SMS} are written and asynchronous communication; \NAME{IM} and chats are written information too, but synchronous. Recorded information are voice mail and video messages as examples for asynchronous communication. VoIP is an example for synchronous communication.
    1.12 @@ -98,7 +98,7 @@
    1.13  \subsubsection*{Unified Communication}
    1.14  \name{Unified communication} is the technology aiming to consolidate and integrate all electronic communication and providing access for all kinds of hardware clients. Unified communication tries to bring the tree trends here mentioned together. The \name{{\smaller PC} Magazine} has the following definition in its Encyclopedia \citeweb{pcmag:uc}: ``[Unified communications is] The real-time redirection of a voice, text or e-mail message to the device closest to the intended recipient at any given time.'' The main goal is to integrate all kinds of communication (asynchronous and synchronous) into one system, hence this requires real-time delivery of data.
    1.15  
    1.16 -According to Michael Osterman \citeweb{howto-def-uc}, unified communications is already possible as far as various incoming sources are routed to one storage where messages can be accessed by one or a few clients. But a system with an ``intelligent parser of a single data stream into separate streams that are designed to meet the real-time needs of the user'' is a goal for the future, he says.
    1.17 +According to \person{Michael Osterman} \citeweb{howto-def-uc}, unified communications is already possible as far as various incoming sources are routed to one storage where messages can be accessed by one or a few clients. But a system with an ``intelligent parser of a single data stream into separate streams that are designed to meet the real-time needs of the user'' is a goal for the future, he says.
    1.18  
    1.19  The question is, if the integration of synchronous and asynchronous message transfer does make sense. A communication between one person talking on the phone and the other replying using his instant messenger, certainly does, if the text-to-speech and speech-to-text converting is fast and the quality good enough. But transferring large video messages and real-time communication data with the same technology, possibly does not.
    1.20  
    1.21 @@ -191,7 +191,7 @@
    1.22  
    1.23  \subsubsection*{New email protocols}
    1.24  
    1.25 -Another concept to redesign the electronic mail system, but this time focused on mail transfer is named ``Internet Mail 2000''. It was proposed by Daniel J.\ Bernstein, the creator of \name{qmail}. Similar approaches were independently introduced by others too.
    1.26 +Another concept to redesign the electronic mail system, but this time focused on mail transfer is named ``Internet Mail 2000''. It was proposed by \person{Daniel~J.\ Bernstein}, the creator of \qmail. Similar approaches were independently introduced by others too.
    1.27  
    1.28  As main change it makes the sender have the responsibility of mail storage; only a notification about a mail message gets send to the receiver, who can fetch the message then from the sender's server. This is in contrast to the \NAME{SMTP} mail architecture, where mail and the responsibility for it is transferred from the sender to the receiver.
    1.29  
    1.30 @@ -221,15 +221,12 @@
    1.31  
    1.32  Provider independence through running an own mail server at home asks for easy configuration of the \MTA. Providers have specialists to configure the systems, but ordinary people do not. Solutions are either having some home service system for computer configuration established with specialists coming to ones home to set up the systems; like it is already common for problems with the power and water supply systems. Or configuration needs to be easy and fool-prove, to be done by the owner himself. The latter solution depends on standardized parts that fit together seamlessly. The technology must not be a problem itself. Only settings custom to the users environment should be left open for him to set. This of course needs to be doable using a simple configuration interface like a web interface. Non-technical educated users should be able to configure the system.
    1.33  
    1.34 -\sendmail\ and \name{qmail} appear to have bad positions at this point. Their configuration is complex, thus they would need simplification wrappers around them to provide easy configuration.
    1.35 -
    1.36 -The approach of wrappers around the main program to make it look easier to the outside is a good concept in general. %FIXME: add ref
    1.37 -It still lets the specialist do complex and detailed configuration, and also offering a simple configuration interface to novices. Further more is it well suited to provide various wrappers with different user interfaces (e.g.\ graphical programs, websites, command line programs; all of them either in a questionnaire style or interactive).
    1.38 +Complex configuration itself is not a problem if simplification wrappers around it do provide an easy interface. The approach of wrappers to make it look easier to the outside is a good concept in general. %FIXME: add ref
    1.39 +It still lets the specialist do complex and detailed configuration, and also offering a simple configuration interface to novices. \sendmail\ took this approach with the \name{m4} macros. %fixme: add ref
    1.40 +Further more is it well suited to provide various wrappers with different user interfaces (e.g.\ graphical programs, websites, command line programs; all of them either in a questionnaire style or interactive).
    1.41  
    1.42  When \MTA{}s become popular on home servers and maybe even on workstations and smart phones, then performance will be less important. Providers need \mta{}s that process large amounts of mail in short time. Home servers or workstations however, do not see that much mail; they need to handle only tens or hundreds of email messages per hour. Thus performance will probably not be a main requirement for an \MTA\ in future, if they mainly run on private machines.
    1.43  
    1.44 -\name{postfix} focuses much on performance, this might not be an important point then.
    1.45 -
    1.46  New mailing concepts and architectures like push email or \name{Internet Mail 2000} will, if they succeed, require \mta{}s to adopt the new technology. \MTA{}s that are not able to change are going to be sorted out by evolution. Thus it is important to not focus too much on one use case, but to stay flexible. Allman saw the flexibility of \sendmail\ one reason for its huge success (see section \ref{sec:sendmail}).
    1.47  
    1.48  Another important requirement for all kinds of software will be security. There is a constant trend coming from completely non-secured software, in the 70s and 80s, over growing security awareness, in the 90s, to security being a primary goal, now. This leads to the conclusion that software security will be even more important in the next years. As more clients get connected to the Internet and especially more computers are listening for incoming connections (like an \MTA\ in a home server), there are more possibilities to break into systems. Securing of software systems will be done with increasing effort in future.
    1.49 @@ -238,7 +235,7 @@
    1.50  
    1.51  Secure and robust software is a pre-requisite for such boxes to make that vision possible.
    1.52  
    1.53 -It seems as if all widely used \mta{}s provide good security nowadays. \name{qmail}'s architecture, also used in \name{postfix}, is generally seen to be conceptually more secure, however.
    1.54 +It seems as if all widely used \mta{}s provide good security nowadays. The modular architecture is generally seen to be conceptually more secure, however.
    1.55  
    1.56  In summary: Easy configuration, as well as the somehow opposed flexibility will be important for future \mta{}s. Also will it be security, but not performance. \MTA{}s might become more commodity software, like web servers already are today, with the purpose to include it in many systems and the need of minimal configuration.
    1.57