james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: [James-NG] Avalon-free James proposal and reference implementation
Date Sun, 30 Jan 2005 21:05:13 GMT
I have a textfile on my desktop with the same name.  Comments below.

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)

+1

>     - single file groovy-based configuration

I prefer spring, but whatever.

>     - multiple domains support from the ground up

You'd have to explain how this works, since SMTP is no-brainer, and POP3 
would not support it.  Basically this is largely a function of account 
name mappers, but would need to be fleshed out.

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

I tried this at one point, but hit some problems for some reason.  There 
are discussions in the mail archive about this.

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

smtp has always been what I was most focused on, and so I'd be curious 
in how this works.  BTW, I would recommend quartz for scheduling.

Also NNTP is gone, but that doesn't matter to me too much.  I'd prefer 
this reduction in James' scope if we were to redo everything.

> 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

All sounds fine, as long as you have something that also is available 
and setup out of the box.

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

Huge +1, except the groovy part, since as I say, I prefer Spring.

I also love groovy and use it wherever I had been considering 
Python/bash scripting and think very highly of it.  I'm just curious how 
you use it for configuration.

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

Errr... nothing is free.  There would be a bunch of work to get this 
implemented and working solidly for the jdbc providers.  I'm curious 
about the licensing of the maildir and mbox providers you're using.

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

So is this a new caching API, or I guess I'm asking, can you swap our 
caching providers so you could use EHCache or OSCache?

> 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

My third kid just turned 2 weeks old, so I can't say when I'll have time 
to review the source, but this is very exciting.

> Any ideas?
> Flames?
> What is wrong with my approach?

Open source projects are made by the people who show up.  I think you're 
taking a good approach, both technically and politically.  This isn't 
going to be an easy change, but I think it's the right one and we need 
someone to can champion this.

-- 
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.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