From: Serge Knystautas
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.
IMO the mailet concept is what make James unique and exciting: the ability for a Java
knowledgeable administrator to implement any specific need that may arise. So
continuing to improve/extend its power, ease of use and flexibility is #1 for me.
I just said though Java knowledgeable: a non Java knowledgeable administrator would
need to choose among a good, increasing and improving but not so rich collection of
official matchers and mailets. I think that the ASF James project should formally
endorse and host, obviously with no responsibility, a site where users can store and
exchange matchers/mailets, of which a part makes up into the official code as now.
Danny's mailet.org was a good initiative, but now is no longer up and running. Was
it successful? probably not, only two contributions - one from Marco Tedone and one
from myself: would it have been more successful if with more visibility from ASF?
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.
Critical also for me.
- All in XML files (or worse, a database)
I consider this quite acceptable. The real problem here IMO is a lack of an offline
syntax checker utility for the configuration files: so many times I had panicly to
correct an error in one of them while the server is down refusing to startup because
of some stupid XML syntax error just made by myself. Some DTD validation should be
possible to be performed by an offline tool before restarting the server.
- Troubleshooting is non-intuitive and tough at best, and
Definitively should be improved.
- No consensus on how to support more complex processing logic (matcher
params, BSD scripting, etc...)
Let's start implementing
http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV3/MailetConfiguration #1 in v2.2.
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...
IMHO (b) is absolutely #1.
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.
Vincenzo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
