On Wednesday 12 November 2003 21:54, Serge Knystautas wrote: > 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.
That might be the case but the mailet concept is what made me choose James in the first place. It is exactly the extensability using mailets/matchers which makes James such a powerfull choice. > > 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. That is a major inconvinience but as other has pointed out should be mainly a container issue. > - All in XML files (or worse, a database) This is not a problem for me personally, but we have several installations spread all over, and sysadms at these sites have very different capabilities. For that reason we have made a simple metaconfiguration, which controls mainly our custom mailets, but also the mailflow in the spool (ie. a metasetting can enable/disable the processor route mails take). This metaconfiguration is a lot simpler (basically properties) so it is easier to guide the sysadm to make certain changes, and we are currently building a GUI ontop of this configuration. > - Troubleshooting is non-intuitive and tough at best, and Yes, It could be better. We are currently thinking about some alarm-service (JMX based, later SNMP) but the problem is where and when to raise the alarms. > - No consensus on how to support more complex processing logic (matcher > params, BSD scripting, etc...) Well is that not what the mailet/matcher API is for? > > 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..? Well I believe that Merlin is a must (IMO Phoenix is dying), but apart from that JBoss etc. is not that interesting. Geronimo might be interesting when it sees the light (is Geronimo Merlin based?) > b. Towards more sysadmin friendly uses, e.g., scripting in protocol > handlers, complex processor logic, etc... This would be my preferred road for the future. > > 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. --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax: +45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
