You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by er...@apache.org on 2011/05/25 13:40:35 UTC
svn commit: r1127477 - in /james/server/trunk/src/site:
resources/js/dev-extend.js resources/js/dev.js xdoc/dev-extend.xml
xdoc/dev.xml
Author: eric
Date: Wed May 25 11:40:34 2011
New Revision: 1127477
URL: http://svn.apache.org/viewvc?rev=1127477&view=rev
Log:
Move images on dev page - bring more information architecture (JAMES-1219)
Removed:
james/server/trunk/src/site/resources/js/dev-extend.js
Modified:
james/server/trunk/src/site/resources/js/dev.js
james/server/trunk/src/site/xdoc/dev-extend.xml
james/server/trunk/src/site/xdoc/dev.xml
Modified: james/server/trunk/src/site/resources/js/dev.js
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/js/dev.js?rev=1127477&r1=1127476&r2=1127477&view=diff
==============================================================================
--- james/server/trunk/src/site/resources/js/dev.js (original)
+++ james/server/trunk/src/site/resources/js/dev.js Wed May 25 11:40:34 2011
@@ -1,4 +1,6 @@
$(function(){
$("#high-level-arch-img-id").fancybox();
$("#high-level-arch-txt-id").fancybox();
+ $("#arch-img-id").fancybox();
+ $("#arch-txt-id").fancybox();
});
Modified: james/server/trunk/src/site/xdoc/dev-extend.xml
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/xdoc/dev-extend.xml?rev=1127477&r1=1127476&r2=1127477&view=diff
==============================================================================
--- james/server/trunk/src/site/xdoc/dev-extend.xml (original)
+++ james/server/trunk/src/site/xdoc/dev-extend.xml Wed May 25 11:40:34 2011
@@ -31,13 +31,6 @@
<section name="Extend James">
- <subsection name="Modules Details">
-
- <a href="images/uml/org.apache.james-package-detail_large.png" id="arch-img-id"><img src="images/uml/org.apache.james-package-detail_small.png"/></a>
- <p><a href="images/uml/org.apache.james-package-detail_large.png" id="arch-txt-id">Click to enlarge image</a></p>
-
- </subsection>
-
<subsection name="Custom Mailet">
<p>See the <a href="dev-extend-mailet.html">mailet</a> page for more information.</p>
Modified: james/server/trunk/src/site/xdoc/dev.xml
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/xdoc/dev.xml?rev=1127477&r1=1127476&r2=1127477&view=diff
==============================================================================
--- james/server/trunk/src/site/xdoc/dev.xml (original)
+++ james/server/trunk/src/site/xdoc/dev.xml Wed May 25 11:40:34 2011
@@ -30,29 +30,57 @@
<body>
- <section name="Functional Architecture">
-
+ <section name="High Level Architecture">
+
+ <a href="images/uml/org.apache.james-package_large.png" id="high-level-arch-img-id"><img src="images/uml/org.apache.james-package_small.png"/></a>
+ <p><a href="images/uml/org.apache.james-package_large.png" id="high-level-arch-txt-id">Click to enlarge image</a></p>
+
<p>James is a multi-protocol message processing and storage engine. James
currently consists of:
<ul>
- <li>Four mail protocol servers: SMTP, POP3, IMAP4 and LMTP.</li>
+ <li>Four mail protocol services: SMTP, POP3, IMAP4 and LMTP.</li>
<li>Support for SMTP Auth.</li>
<li>A remote administration server.</li>
<!-- <li>an NNTP server,</li>-->
- <li>Support for TLS (SSL) for mail protocols and remote administration.</li>
+ <li>Support for TLS/SSL.</li>
<li>A mail processing engine that supports the Mailet API.</li>
<li>File-system message storage and a message storage interface to RDBMS's.</li>
<li>File-system user record storage and an experimental interface to LDAP directories.</li>
</ul>
</p>
-
+
+ <p>The mail protocol services use the mailbox librairies to fetch/store mails.</p>
+
+ <p>When a mail arrives via SMTP, it gets processed by the SMTP services and is placed
+ in a Apache ActiveMQ queue (ActiveMQ is the Java Messaging Service JMS implementation at Apache)</p>
+
+ <p>This allow to decouple mail spooling from the rest of the incoming traffic.</p>
+
+ <p>After being the put in the queue, the mailetcontainer is responsible to get the
+ next mail to process from the ActiveMQ queue.</p>
+
+ <p>The mailets defined in mailetcontainer.xml are applied to define if the mail is to be
+ treated as a Local or Remote delivery.</p>
+
+ <p>The Local and Remote deliveries are treated by their corresponding mailet.</p>
+
+ <p>The LocalDelivery mailet uses the SieveMailet which uses the mailbox/message manager to store the mail.</p>
+
+ <p>The result of the mail can be either:</p>
+ <ul>
+ <li>Gets stored in the mailbox.</li>
+ <li>Gets relayed to another server.</li>
+ <li>Gets relayed to another server.</li>
+ <li>Gets bounced back if it can not be handle by the james instance (this may happen during a previous step)</li>
+ <li>Gets stored in the "mailstore" which is a special format for spam, virus,... (in future release, we may also store those mails in the mailbox).</li>
+ </ul>
</section>
<section name="Technical Architecture">
- <a href="images/uml/org.apache.james-package_large.png" id="high-level-arch-img-id"><img src="images/uml/org.apache.james-package_small.png"/></a>
- <p><a href="images/uml/org.apache.james-package_large.png" id="high-level-arch-txt-id">Click to enlarge image</a></p>
-
+ <a href="images/uml/org.apache.james-package-detail_large.png" id="arch-img-id"><img src="images/uml/org.apache.james-package-detail_small.png"/></a>
+ <p><a href="images/uml/org.apache.james-package-detail_large.png" id="arch-txt-id">Click to enlarge image</a></p>
+
<p>James uses many other components: Spring, ActiveMQ, OpenJPA, Netty, Jackrabbit, Derby...</p>
<p>The modules can be classified into 3 categories:</p>
@@ -62,15 +90,15 @@
<li>Functions: Everything else. It is harder to see a case of "direct" reuse of a function jar. Most times we'll only have code reuse. It is preferable to limit Function to Functions dependencies.</li>
</ul>
+ </section>
+
<section name="Server Coding Guidelines">
- <p>LogEnabled interface as the preferred way, except for non-server code and classes that have no bean definition.</p>
- <p>LogEnabled should be used wherever logging is needed and no "session-scoped" Log is provided.</p>
+ <p>LogEnabled interface as the preferred way, except for non-server code and classes that have no bean definition.
+ LogEnabled should be used wherever logging is needed and no "session-scoped" Log is provided.</p>
</section>
- </section>
-
<section name="Design Objectives">
<subsection name="Features">
@@ -91,13 +119,13 @@
works alone without the need for any other server or solution.</p>
<p><i><b>Mailet support</b></i> Apache James supports the Apache Mailet API. A Mailet
- is a discrete piece of mail-processing logic which is incorporated into
- a Mailet-compliant mail-server's processing. This easy-to-write,
- easy-to-use pattern allows developers to build powerful customized mail
- systems. Examples of the services a Mailet might provide include: a
- mail-to-fax or mail-to-phone transformer, a filter, a language translator, a mailing
- list manager, etc. Several Mailets are included in the James
- distribution (see <a href="dev-provided-mailets.html">documentation</a>).</p>
+ is a discrete piece of mail-processing logic which is incorporated into
+ a Mailet-compliant mail-server's processing. This easy-to-write,
+ easy-to-use pattern allows developers to build powerful customized mail
+ systems. Examples of the services a Mailet might provide include: a
+ mail-to-fax or mail-to-phone transformer, a filter, a language translator, a mailing
+ list manager, etc. Several Mailets are included in the James
+ distribution (see <a href="dev-provided-mailets.html">documentation</a>).</p>
<p><i><b>Resource abstraction</b></i> Like protocols, resources are abstracted and,
accessed through defined interfaces (JavaMail for transport, JDBC for
@@ -118,43 +146,43 @@
<p>It is the existence of published "open" standards which
allows independant teams to develop interoperable software.</p>
- <p>James attempts to support a number of these standards most of which are
- IETF RFC's and in the areas covered by these standards the published standard
- is our requirements document.</p>
-
- <p>This sometimes leads to confusion where behaviour is not
- the subject of a relevant standard, or conflict where common
- (de-facto) behaviour is actually at odds with a supported standard.</p>
-
- <p>We believe that it is our responsibility to adhere to the published standard.
- If we allow our implementation to deviate it means that we are tacitly encouraging
- the situation whereby interoperability is no longer guarenteed by standards
- compliance alone, but also requires access to undocumented and possibly
- even commercially licenced technology. There is no easy route for a
- newcomer to aquire these secrets, and interoperabilty
- becomes something only available to the elite.</p>
-
- <p>The James policy for issues of non-compliance tries to tread the fine line
- between a pragmatic acceptance of other people's misinterpretation of the
- RFC's and an evangelical defence of open standards as the key to freedom of interoperation.</p>
-
- <p>In practice this policy is that certain well argued of cases of
- non-compliance which can be *safely* worked around, will be tolerated by
- James.</p>
-
- <p>In cases (like jira issue JAMES-344) where variance from a published standard is
- required it is desirable that this functionality is disabled in James by default,
- it must be prominently and clearly documented that this causes James
- to violate the relevant standard, and should be enabled by explicit
- configuration, making its use a conscious decision of the user rather
- than an decision taken by the James team.</p>
-
- <p>In cases where the required behaviour is not within the scope of any standard which
- James claims to support (such as behaviour which is a de-facto standard or
- an <i>internet draft</i> RFC but not yet subject of a <i>standards track</i> RFC) it is
- acceptable to implement the behaviour so long as it is adequately
- documented (for instance by refrence to an <i>internet draft</i> or
- other public document) and users can be clear about what to expect from James.</p>
+ <p>James attempts to support a number of these standards most of which are
+ IETF RFC's and in the areas covered by these standards the published standard
+ is our requirements document.</p>
+
+ <p>This sometimes leads to confusion where behaviour is not
+ the subject of a relevant standard, or conflict where common
+ (de-facto) behaviour is actually at odds with a supported standard.</p>
+
+ <p>We believe that it is our responsibility to adhere to the published standard.
+ If we allow our implementation to deviate it means that we are tacitly encouraging
+ the situation whereby interoperability is no longer guarenteed by standards
+ compliance alone, but also requires access to undocumented and possibly
+ even commercially licenced technology. There is no easy route for a
+ newcomer to aquire these secrets, and interoperabilty
+ becomes something only available to the elite.</p>
+
+ <p>The James policy for issues of non-compliance tries to tread the fine line
+ between a pragmatic acceptance of other people's misinterpretation of the
+ RFC's and an evangelical defence of open standards as the key to freedom of interoperation.</p>
+
+ <p>In practice this policy is that certain well argued of cases of
+ non-compliance which can be *safely* worked around, will be tolerated by
+ James.</p>
+
+ <p>In cases (like jira issue JAMES-344) where variance from a published standard is
+ required it is desirable that this functionality is disabled in James by default,
+ it must be prominently and clearly documented that this causes James
+ to violate the relevant standard, and should be enabled by explicit
+ configuration, making its use a conscious decision of the user rather
+ than an decision taken by the James team.</p>
+
+ <p>In cases where the required behaviour is not within the scope of any standard which
+ James claims to support (such as behaviour which is a de-facto standard or
+ an <i>internet draft</i> RFC but not yet subject of a <i>standards track</i> RFC) it is
+ acceptable to implement the behaviour so long as it is adequately
+ documented (for instance by refrence to an <i>internet draft</i> or
+ other public document) and users can be clear about what to expect from James.</p>
</subsection>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org