I have a textfile on my desktop with the same name. Comments below.
Really glad about it :)
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 upYou'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.
POP3 Example 1: user joe +ok enter password pass mypass +ok [EMAIL PROTECTED] authenticated
POP3 Example 2: user [EMAIL PROTECTED] +ok enter password pass otherpass +ok [EMAIL PROTECTED] authenticated
[EMAIL PROTECTED] and [EMAIL PROTECTED] are completely different joes (configurable) that may have different storage type (maildir, mbox, etc.) and authenticate against different userstores (unix /etc/passwd authentication, LDAP, whatever userstore you write)
userid always has a domain part
by default the domain part equals to the hostname of your machine
Yes you have to tell your Outlook users to type [EMAIL PROTECTED] instead of just joe in the Login box. But you can configure the default domain to be not your machines hostname but rather "virtual.com" and all default-no-domain joes will be mapped to [EMAIL PROTECTED]
Is this approach wrong?
Well it depends on the store providers you use. Definitely you'll have problems if the provider is written from the client perspective.
I tried this at one point, but hit some problems for some reason. There are discussions in the mail archive about this.- 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
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.
smtp integration is my priority number one quartz agreed, no problems
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.I know nothing about NNTP (no experience) so if someone needs it they are welcome to add support for it - no constraints are placed.
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.
Good point. For the out-of-the-box part we can use James v2 db/ldap schema.
Spring is a container, for now the configuration and amount of components is not too large to use container (arguable). So I decided a single groovy script would be fine.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.Please refer to
http://devel.priocom.com:8083/viewrep/JamesNG/container/src/groovy/DummyConfig.groovy?r=1.3
for an example of default dummy configuration in a single groovy script assembling, configuring and starting all necessary components.
Maildir is javamaildir (javamaildir.sf.net) written by me and licensed to apache james to use in a way you like :)
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.
Mbox is weeeell modified GNU mbox provider (I know its GPL but maybe we can try to convience Chris Burdess to license it for James)
I would volunteer to start work on JDBC provider since I have some experience writing providers.
No problem, it is just a statement that cache is there and stores are not reopened on every use authentication.
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?
I bet my caching api is easily replaced by more advanced caches out there and since i am not an expert in caches i would prefer it replaced.
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.
You can check the groovy configuration examples available at http://devel.priocom.com:8083/viewrep/JamesNG/container/src/groovy
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.
Thanks a lot for your reply It was my more than 2 year long goal to improve james substantialy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
