james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Albert Kwong <mandr...@yahoo.com>
Subject Re: [James-NG] Avalon-free James proposal and reference implementation
Date Mon, 31 Jan 2005 01:54:43 GMT
Any consideration on using HiveMind as the container?

Albert

 --- Gabor Kincses <npure2001@yahoo.com> 內容:
> 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
> > 
> > 
> 
> 
> =====
> 
=== message truncated === 

=====
Are you an MBA?  Check out http://www.mba.hk for value added services.

---------------------------------------------------------------------
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