james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Zhukov <zhu...@ukrpost.net>
Subject [James-NG] Avalon-free James proposal and reference implementation
Date Sun, 30 Jan 2005 18:17:43 GMT
Hi, James hackers!

Recently on the mailing list I saw messages of departure from 
avalon-based container
So i decided to propose my ideas and reference implementation as a basis 
of next generation james
(i hope avalon-free version) which i propose to call jamesng

nice points in jamesng for apache james are:
	- components are independent POJOs (CDI IoC) so no funky
	  interface has to be implemented to extend james-ng
	- single file groovy-based configuration
	- multiple domains support from the ground up
	- adaptable user stores (enterprise does not want to change its
           db/ldap directory/whatever) (see ENTERPRISE DB)
	- javax.mail.Store/Folder based mail repositories support
           hierarhical folders, tested with Maildir and mbox providers
           (see STORES)
	- extensive support for folder/store/user caching to speed-up
           servers (see CACHING)
	- imap4 support (not complete but usable)
	- pop3 support
	- independent components can be easily added and integrated into
           build system

things laking:
	- smtp support - no spooling/remote deliveries, working on it
           right now

server is large ISP/enterprise targeted which means
- support for multiple domains on a single/multiple IP addresses,
- highly configurable user stores - database should not be designed for 
use with james (as it is with current james)
but rather user store adapts to the existing userstores of an 
Often enterprises already have their user databases often they contain 
legacy elements which such companies
just very much hesitate to change to something new.
Above mentioned is very much true for LDAP directories - you cannot 
expect an enterprise to change its
LDAP directory to fit james in

All components of james-ng are POJOs no component _must_ implement some 
funky interface to be included in the server.
Components adhere CDI style IoC which besides other advantages allows 
configuration to be a single groovy file.
The task of groovy configuration is to assemble all components together.

Mail stores (repositories) are plain javax.mail.Store providers.
Since javax.mail.Folder interface supports hierarchy james-ng gets 
"free" IMAP support - no need to reengineer mail
repository to access folders/sub-folders. However to support all of IMAP 
features such provider's Folder implementation
must as well implement UIDFolder interface to support IMAP UID operations.
For now tested are Maildir and mbox providers, but apparently nothing 
prevents to write/use existing jdbc providers
that would store mails in database.
Simple groovy-based configuration allows administrator to configure 
different types of stores for different users.

I am currently in charge of rather large (150k+ users) free webmail with 
multiple domains
and i dont have very new and high-performing hardware to host it so i 
designed the server for performance.
The main point is to avoid unproductive waste of performance (very much 
true for most unix mail servers)
stores/folders opened by users as well as user objects are cached 
(certainly you can turn the cache off) instead of being
open on every user login. Very much helps for polling clients which 
disconnect and connect back in 10 minutes.
Administrator can adjust the caching policy, for now implemented are 
LRUCache and GCCache (reference map based cache).

If you are reading this then you are ready to see what does jamesng look 
Since the codebase is pretty large for an attachment to email I have 
setup cvs repostitory as well as source release repository.

Source release:
Binary release

I suggest you download source release and build binary release or just 
download binary release to play with the groovy
all-in-one configuration.

Anonymous CVS access:
     anoncvs user has empty password

FishEye (like viewcvs but better and in java)
     You can also download the latest cvs checkout tarball at

As steps further steps to develop apache james i propose:
     - create a new branch in svn called "JAMES_NG" or the like
     - give up using avalon container in this branch
     - either use one of the existing CDI containers (picocontainer) or 
accept proposed groovy-based config files
     - merge smtp/mailer/mailet code into JAMES_NG branch
     - use the branch as a basis for James v3

Any ideas?
What is wrong with my approach?

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message