I would vote for b) Much better admin, and make it extensible like like the mailet and matcher Like you said, be able to load mailets and matchers dynamically. Continue down the scalability/robustness path
that would be the order of my preferences. I don't care what container it runs in. Cheers, Steve -----Original Message----- From: Serge Knystautas [mailto:[EMAIL PROTECTED] Sent: Wed 11/12/2003 12:54 PM To: James Developers List Cc: Subject: Future direction for James 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 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
