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 22:08:00 GMT
Gabor Kincses wrote:
> Does using groovy mean using nanocontainer as well? 
> Lightweight containers are great.  I personally think
> constructor dependency injection is the right way to
> go.
Jamesng is just an attempt to move james away from avalon, for now the 
configuration and amount of components is not too large to use 
nanocontainer.
So I decided to use a single groovy script to integrate all components 
together. Well I have to say it is becoming more complex so maybe we 
should move to nanocontainer, but for now i dont use it.
Any suggestions, code contributions are welcome.

Check out the DummyConfig.groovy (the default config for the jamesng 
using DummyUserStore and maildir as storage) to see for yourself how all 
components are assembled, configured and started.
http://devel.priocom.com:8083/viewrep/JamesNG/container/src/groovy/DummyConfig.groovy?r=1.3

Answering your question: yes, lightweight containers are great and 
nanocontainer is great as well, but the configuration is so lightweight 
for now that even nanocontainer seems to be an overkill.

You are more than welcome to prove me wrong.

> 
> Thanks,
> Gabor
> 
> --- Alexander Zhukov <zhukov@ukrpost.net> 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
>>
>>ENTERPRISE DB
>>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
>>
>>COMPONENTS
>>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.
>>
>>STORES
>>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.
>>
>>CACHING
>>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
>>
>>
> 
> 
> 
> =====
> Gabor Kincses
> Running Mandrake Linux 10.0
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> The all-new My Yahoo! - Get yours free! 
> http://my.yahoo.com 
>  
> 



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


Mime
View raw message