> 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]
