docs/diploma
diff thesis/tex/2-MarketAnalysis.tex @ 373:d51894e48762
started indexing; mta -> MTA (many small changes)
author | meillo@marmaro.de |
---|---|
date | Sat, 31 Jan 2009 21:39:53 +0100 |
parents | 80b2e476c2e3 |
children | 3445852ed736 |
line diff
1.1 --- a/thesis/tex/2-MarketAnalysis.tex Sat Jan 31 20:07:58 2009 +0100 1.2 +++ b/thesis/tex/2-MarketAnalysis.tex Sat Jan 31 21:39:53 2009 +0100 1.3 @@ -65,12 +65,12 @@ 1.4 1.5 1.6 \subsection{Trends} 1.7 -Following are the trends for electronic communication. The trends are shown from the view point of \mta{}s. Nevertheless are these trends common for all of the communication technology. 1.8 +Following are the trends for electronic communication. The trends are shown from the view point of \MTA{}s. Nevertheless are these trends common for all of the communication technology. 1.9 1.10 \subsubsection*{Consolidation} 1.11 There is a consolidation of communication technologies with similar transport characteristics, nowadays. Email is the most flexible kind of asynchronous communication technology in major use. Hence email is the best choice for transferring messages of any kind today. But in future it probably will be \name{Unified Messaging}, which tries to group all kinds of asynchronous messaging into one communication system. It aims to provide transparent transport for all kinds of content and flexible access interfaces for all kinds of clients. Unified messaging seems to have the potential to be the successor of all asynchronous communication technologies, including email. 1.12 1.13 -Today email still is the major asynchronous communication technology and it probably will be it for the next years. As Unified Messaging needs similar transfer facilities to email, it may to be an evolution not a revolution. Hence \mta{}s will still have importance in future, maybe in a modified way. 1.14 +Today email still is the major asynchronous communication technology and it probably will be it for the next years. As Unified Messaging needs similar transfer facilities to email, it may to be an evolution not a revolution. Hence \MTA{}s will still have importance in future, maybe in a modified way. 1.15 1.16 1.17 \subsubsection*{Integration} 1.18 @@ -119,7 +119,7 @@ 1.19 1.20 %fixme: add short summery: where exactly is masqmail's position within e-comm? 1.21 1.22 -After viewing the whole market of electronic communication, a zoom into the market of electronic mail follows. Email is an asynchronous communication technology that transports textual information primary. This thesis is about a \mta, so the market situation for email is important. Interesting questions are: Is email future-safe? How will electronic mail change? Will it change at all? Which are the critical parts? These questions matter when deciding on the directions for further development of an \MTA. They are discussed in this section. 1.23 +After viewing the whole market of electronic communication, a zoom into the market of electronic mail follows. Email is an asynchronous communication technology that transports textual information primary. This thesis is about an \MTA, so the market situation for email is important. Interesting questions are: Is email future-safe? How will electronic mail change? Will it change at all? Which are the critical parts? These questions matter when deciding on the directions for further development of an \MTA. They are discussed in this section. 1.24 1.25 1.26 1.27 @@ -196,7 +196,7 @@ 1.28 1.29 Home servers become popular for central data storage and multimedia services, these days. Being assembled of energy efficient elements, power consumption is no big problem anymore. These home servers will replace video recorders and \NAME{CD} music collections in the near future. It is also realistic that they will manage heating systems and intercoms too. Given the future leads to this direction, it will be a logical step to have email and other communication provided by the own home server as well. 1.30 1.31 -After \mta{}s have not been popular for users in the past years, the next years might bring the \MTA{}s back to the users. Maybe in a few years nearly everyone will have one running at home. 1.32 +After \MTA{}s have not been popular for users in the past years, the next years might bring the \MTA{}s back to the users. Maybe in a few years nearly everyone will have one running at home. 1.33 1.34 1.35 \subsubsection*{Pushing versus polling} 1.36 @@ -239,16 +239,16 @@ 1.37 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.38 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.39 1.40 -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. However, there is no need for home servers and workstations to handle that much mail; they need to process far less email messages per time unit. Thus performance will probably not be a main requirement for an \MTA\ in future, if they mainly run on private machines. 1.41 +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. However, there is no need for home servers and workstations to handle that much mail; they need to process far less email messages per time unit. Thus performance will probably not be a main requirement for an \MTA\ in future, if they mainly run on private machines. 1.42 1.43 -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 not to focus too much on one use case, but to stay flexible. \person{Allman} saw the flexibility of \sendmail\ one reason for its huge success (see section \ref{sec:sendmail}). 1.44 +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 not to focus too much on one use case, but to stay flexible. \person{Allman} saw the flexibility of \sendmail\ one reason for its huge success (see section \ref{sec:sendmail}). 1.45 1.46 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 within 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.47 1.48 ``Plug-and-play''-able hardware with preconfigured software running can be expected to become popular. Like someone buys a set-top box to watch Pay-\NAME{TV} today, he might be buying a box acting as mail server in a few years. He plugs the power cable in, inserts his email address in a web interface and selects the clients (workstation computers or smart phones) to which mail should be send and from which mail is accepted to receive. That's all. It would just work then, like everyone expects it from a set-top box today. Secure and robust software is a pre-requisite for such boxes to make that vision possible. 1.49 1.50 1.51 -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.52 +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.53 1.54 1.55