james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabor Kincses <npure2...@yahoo.com>
Subject Re: [James-NG] Avalon-free James proposal and reference implementation
Date Sun, 30 Jan 2005 21:52:51 GMT
Does using groovy mean using nanocontainer as well? 
Lightweight containers are great.  I personally think
constructor dependency injection is the right way to
go.

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