james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Zhukov <zhu...@ukrpost.net>
Subject Re: [James-NG] Avalon-free James proposal and reference implementation
Date Sun, 30 Jan 2005 21:59:24 GMT
Laszlo Hornyak wrote:
> Hi!
> I am new to the list. I see that avalon dependency received couple of 
> critics on the list. Why is avalon 'bad' and what is the intention of 
> the james team with this?
I dont say avalon is bad I just think CDI approach is more scalable and 
easier to understand. To form your own opinion please refer to Martin 
Fowlers article "Inversion of Control Containers and the Dependency 
Injection pattern"
Among benefits of CDI IoC is high level of component decoupling that is 
your components may not depend on each other or have any requirement 
that is a show-stopper to include your component into the software you 
are developing.

> Laszlo
> Alexander Zhukov wrote:
>> 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
>>       (see COMPONENTS)
>>     - 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 
>> isp/enterprise.
>> 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 like.
>> Since the codebase is pretty large for an attachment to email I have 
>> setup cvs repostitory as well as source release repository.
>> Source release:
>> http://devel.priocom.com/jamesng/jamesng-20050130-src.tar.gz
>> Binary release
>> http://devel.priocom.com/jamesng/jamesng-20050130.tar.gz
>> 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:
>>     CVSROOT=":pserver:anoncvs@devel.priocom.com:/export/cvsroot/jamesng"
>>     anoncvs user has empty password
>> FishEye (like viewcvs but better and in java)
>>     http://devel.priocom.com:8083/viewrep/JamesNG
>>     You can also download the latest cvs checkout tarball at
>> http://devel.priocom.com:8083/viewrep/~tarball=tgz/JamesNG/JamesNG.tgz
>> 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?
>> Flames?
>> 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
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org

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

View raw message