james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Future direction for James
Date Wed, 12 Nov 2003 20:54:14 GMT
James was originally created for the mailet concept, i.e., Java based 
email processing.  This has been done "ok" so far.. the 2.2 release has 
a better classloader that makes it easier to do this, but there still 
hasn't emerged a great Mailet SDK/IDE plug-in.

Meanwhile, James is being adopted as a straight email server 
replacement.  The code is much more scalable, and we've got notional 
requirements from ASF infrastructure that we're using as a target.

IMHO, one area that James struggles is configurability:
- Restart for every conf change.
- All in XML files (or worse, a database)
- Troubleshooting is non-intuitive and tough at best, and
- No consensus on how to support more complex processing logic (matcher 
params, BSD scripting, etc...)

Looking over the config files for qmail on ASF infrastructure makes you 
appreciate the expertise that the ASF has.  The large files with rules 
to block emails based on subject or attachment patterns is, well, 
impressive.  Right now James has no manageable way to support this.

At the same time, we get questions about extracting protocol handlers, 
embedding in JBoss or other apps, and otherwise componentizing James.

I'm curious to see where people think James should go...
a. Push towards more developer friendly uses, e.g., embedding in 
different Avalon containers, w/JBoss, extractable protocol handlers, etc..?
b. Towards more sysadmin friendly uses, e.g., scripting in protocol 
handlers, complex processor logic, etc...

These aren't mutually exclusive goals, and I recognize the real driver 
will be people making these changes.  Nonetheless, I'm curious what 
people think.

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

View raw message