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 President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
