james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laszlo Hornyak <ko...@forgeahead.hu>
Subject Re: [James-NG] Avalon-free James proposal and reference implementation
Date Sun, 30 Jan 2005 20:47:43 GMT

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?


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

View raw message