docs/diploma: thesis/tex/2-MarketAnalysis.tex comparison

comparison thesis/tex/2-MarketAnalysis.tex @ 396:8ef85e22ff7d

again lots of fixes and removed fixmes

author	meillo@marmaro.de
date	Sat, 07 Feb 2009 19:00:25 +0100
parents	0d78755132b7
children	13e630c5a44d

comparison

equal deleted inserted replaced

-:0d78755132b7
+:8ef85e22ff7d
 Opportunities of the market are large data transfers, originating in multimedia content, which becomes popular. If email is used as basis for Unified Messaging, lots of voice and video mail will be transferred. Email is weak related to this kind of data: The data needs to be encoded to \NAME{ASCII} which stresses mail servers a lot. Additionally a lot of traffic is generated by the \name{store-and-forward} transfer, which \SMTP\ uses.
 \index{um}
 \index{store-and-forward}
-The use of different hardware to access mail is another opportunity of the market. But as more hardware gets involved, the networks become more complex. Thus the need for more software and infrastructure to transfer mail within the growing network might be a weakness of the email system. %fixme: think about that
+The use of different hardware to access mail is another opportunity of the market. But as more hardware gets involved, the networks become more complex. Thus the need for more software and infrastructure to transfer mail within the growing network might be a weakness of the email system.
-An opportunity of the market and at the same time a strength of electronic mail is its standardization. Few other communication technologies are standardized, and thus freely available, in a similar way. %fixme: ref
+An opportunity of the market and at the same time a strength of electronic mail is its standardization. Few other communication technologies are standardized, and thus freely available, in a similar way. Another opportunity and strength is the modular and extensible structure of electronic mail; it can easily evolve to new requirements.
-Another opportunity and strength is the modular and extensible structure of electronic mail; it can easily evolve to new requirements. %fixme: ref
 \index{email!standardiziation}
 The increasing integration of communication channels is an opportunity for the market. But deciding whether it is a weakness or strength of email is difficult. Due to the impossibility to integrate synchronous stream data and large binary data, it is a weakness. But it is also a strength, because arbitrary asynchronous communication data already can be integrated. On the other hand, the integration might be a threat too, because integration often leads to complexity of software. Complex software is more error prone and thus less reliable. This, however, could again be a strength of electronic mail because its modular design decreases complexity.
 Figure~\ref{fig:email-swot} displays the \NAME{SWOT} analysis in a handy overview. It is obvious to see, that the opportunities outweigh. This is an indicator for a still increasing market. %fixme: ref
 \subsubsection*{Pushing versus polling}
 \index{push email}
 The retrieval of email is a field that is also about to change these days. The old way is to fetch email by polling the server that holds the personal mailbox. This polling is normally done in regular intervals, often once every five to thirty minutes. The mail transfer from the mailbox to the \MUA\ is initiated from the user side. The disadvantage herewith is the delay between the arrival of mail on the server and the time when the user finally has the message on his screen.
-To remove this disadvantage, \name{push email} was invented. Here the server is not polled every few minutes about new mail, but the server pushes new mail directly to the client on arrival. The transfer is initiated by the server. This concept became popular with smart phones; they were able to do emailing but the traffic caused by polling the server was expensive.
+To remove this disadvantage, \name{push email} \citeweb{pushemail.co.uk} was invented. Here the server is not polled every few minutes about new mail, but the server pushes new mail directly to the client on arrival. The transfer is initiated by the server. This concept became popular with smart phones; they were able to do emailing but the traffic caused by polling the server was expensive.
 The concept works well with mobile phones where the provider knows about the client, but it does not seem to be a choice for computers, since the provider needs to have some kind of login to push data to the user's computer. Push email, however, could swap over to computers when using a home server and no external provider. A possible scenario is a home server which receives mail from the Internet and pushing it to own workstations and smart phones. The configuration could be done by the user by using some simple interface, like one configures his telephone system to have different telephone numbers ringing on specified phones.
-%FIXME: add reference to push email
 Another problem is when multiple clients share one mailbox. This is only solvable by working directly in the server's mailbox, which causes lots of traffic, or by storing at least information about read messages and the like there.
 \subsubsection*{New email concepts}
-Changing requirements for email communication lead to the need for new concepts and new protocols that cover these requirements. One of these concepts to redesign the email system is named \name{Internet Mail 2000}. It was proposed by \person{Daniel~J.\ Bernstein}, the creator of \qmail. Similar approaches were independently introduced by others, too.
+Changing requirements for email communication lead to the need for new concepts and new protocols that cover these requirements. One of these concepts to redesign the email system is named \name{Internet Mail 2000} \citeweb{im2000}. It was proposed by \person{Daniel~J.\ Bernstein}, the creator of \qmail. Similar approaches were independently introduced by others, too.
-%FIXME: add references for IM2000
 \index{Internet Mail 2000}
-As main change, the sender has the responsibility for mail storage; only a notification about a mail message gets sent to the recipient. The recipient can then 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 (see \name{store-and-forward}).
+As main change, the sender has the responsibility for mail storage; only a notification about a mail message gets sent to the recipient. The recipient can then fetch the message then from the sender's server. This is in contrast to the \SMTP\ mail architecture where mail and the responsibility for it is transferred from the sender to the receiver. (See page~\pageref{smtp-intro} for the \name{store-and-forward} principle.)
-%fixme: reference to the store-and-forward concept
 \index{smtp!store-and-forward}
 \MTA{}s are still important in this new email architecture, but in a slightly different way. They do not transfer mail itself anymore, but they transport the notifications about new mail to the destinations. This is a quite similar job as in the \NAME{SMTP} model. The real transfer of the mail, however, can be done in an arbitrary way, for example via \NAME{FTP} or \NAME{SCP}.
 A second concept, this one primary to arm against spam, is \person{David~A.\ Wheeler}'s \name{Guarded Email} \cite{wheeler03}. It requires messages to be recognized as Ham (non-spam) to be accepted, otherwise a challenge-response authentication will be initiated.
 \paragraph{Easy configuration}
 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-proof, so it can 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 that are 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.
 \index{easy configuration}
-Complex configuration itself is not a problem if simplification wrappers 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
+Complex configuration itself is not a problem if simplification wrappers provide an easy interface. The approach of wrappers to make it look easier to the outside is a good concept in general. It still lets the specialist do complex and detailed configuration while also a simple configuration interface to novices is offered. \sendmail\ took this approach with the \name{m4} macros \cite{sendmail:config}. Further more is this approach 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).
-It still lets the specialist do complex and detailed configuration while also a simple configuration interface to novices is offered. \sendmail\ took this approach with the \name{m4} macros. %fixme: add ref
-Further more is this approach 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).
 \index{sendmail!m4 macros}
 \paragraph{Performance}
 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. 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, given they mainly run on private machines.
 \index{performance}
 \paragraph{Unified Communication}
 Unified Communication, as next step after Unified Messaging, is about the integration of synchronous and asynchronous communication channels. It seems \emph{im}possible to merge the two worlds on basis of email in an evolutionary way. As only a revolutionary change of the whole email concept would make that merge possible, it is best to ignore it. New designed technologies are usually superior to heavily patched and bent old technologies, anyway. A general merge of synchronous and asynchronous communication has good chances to be fatal for email.
 Until Unified Communication will become reality---if ever---electronic mail has a good position, also as basis for Unified Messaging.
-\paragraph{SWOT analysis}
+\paragraph{\NAME{SWOT} analysis}
 Not only the market influences email's future safety, but also must the email technology itself evolve to satisfy upcoming needs. Actions to take were discovered by using the \NAME{SWOT} analysis. These are: Prepare against spam. Search solutions for large data transfers and increasing growth and ramification of networks. Exploit standardization, modularity, and extendability.
 \paragraph{Trends}
 Also needed is awareness for new trends like: Provider independence, new delivery concepts, and completely new emailing concepts that introduce new protocols. Easy configuration, as well as the somehow opposed flexibility, will be important, but not performance. Security will be essential.
 What kinds of \MTA{}s will be needed in future? Probably ones running on home servers and workstations. This is what \masqmail\ was designed for. The dial-up Internet connections, which are central to \masqmail's design, become rare, but mobile clients that move between different networks do need similar concepts, too. This makes \masqmail\ still be a good \MTA\ for such usage. Additionally, \masqmail\ is small and it is much easier to configure for setups that are common to workstations and home servers, than other \MTA{}s.
 \MTA{}s might become more commodity software, like web servers already are today, with the purpose to be included in many systems with only minimal configuration.
-\masqmail\ is a valuable program for various situations. Some setups became rare, but others are expected to become popular in the next years. \masqmail's niche will rather grow than shrink.
+\masqmail\ is a valuable program for various situations. Some setups became rare, but others are expected to become popular in the next years. It is expected that \masqmail's niche will rather grow than shrink.
-%fixme: rewrite that last sentence; add a new heading ``conclusion''? think about it!

Mercurial > docs > diploma

comparison thesis/tex/2-MarketAnalysis.tex @ 396:8ef85e22ff7d