9 Replies Latest reply on Apr 18, 2004 2:41 PM by Andrew Oliver

    RT: Ideas to take from JAMES and Mail Scripting

    Andrew Oliver Master

      Take a look at this: http://james.apache.org/provided_matchers_2_1.html, and this: http://james.apache.org/provided_mailets_2_1.html.

      James has an API called the "Mailet API". Its a great idea but kind of an abortive impelmentation: http://james.apache.org/mailet_api_2_1.html.

      "
      The Mailet API is currently in its second revision. Although, the Mailet API is expected to undergo substantial changes in the near future, it is our aim that existing Mailets that abided purely by the prior Mailet API interfaces will continue to run with the revised specification.
      "

      I don't want to hook into their Mailet API, but rather implement some of the concepts mixed with some of our own. Later I'll start pushing to come together and come up with a "standard" which implements some from both. I know there are a (primarily uninvolved in more than commenting) number of peace/love commentors, but the secret to good design is divergence and reconvergence. Its premature to cooperate. Go look at the best standards and worst. The worst were cooperative from the start, design by committee. The best were competitive and then agreements were met on which ideas had been the best.

      What I'd like to do is see us make a MailListenerChain interface which is itself a MailListener. The MailListener interface is ATM not supposed to pull mails off the stack. A ChainableMailListener would plug into the MailListenerChain and COULD pull messages off the stack.

      From there we implement a concept like Matchers which can plug into a ChainableMailListener.

      ChainableMailListeners should ALSO be MailListeners so they CAN operate in either mode. If they are not part of a chain, they do not consume messages from the stack. If they are part of the chain, they do consume messages from the stack where appropriate.

      Next, I'd like to do more than just statically compiled Java objects for mail processing. For what I'd like to see us do, you need to look at Cocoon's flowscript. Cocoon is a vernable hotbed of good ideas gone bad. Flow is one of them. http://cocoon.apache.org/2.1/userdocs/flow/api.html

      Cocoon uses a Mozilla project called Rhino: http://www.mozilla.org/rhino/. Rhino is a Java implementation of JavaScript (for all irony). There is also jyThon (http://www.ociweb.com/jnb/archive/jnbMar2001.html) but there are reasons that I favor JavaScript to python. The most important is that I see some admin types as writing these mail scripts. JavaScript is more well known than python and probably anyone even somewhat introduced to the technical field has had a basic introduction to it. I mean this is the first language of scripting.

      What the idea would be. Matchers could be implemented in JavaScript as well as Java. We'd supply an object model which protects you from doing anything other than matching mails. Secondly, a RhinoChainableMailListener could be used to do more advanced things with routed mails. You could implement a set of spam filters for instance.

      This has multiple implications. We could also provide a system for syndicating JavaScript matchers for Spam filtering. Basically an RSS feed from a server could be aggregated to provide an automatic method for syndicating filters for spam. Meaning if I trust jboss.org and JBoss.org adds a matcher to its spam filter for all mails containing "V|4GR4" then it would be added to my matcher. If your mail server trusted mine to provide this info, it would be automatically added to yours as well!

      So obviously I've left out some details and there are some rough spots to work out. In particular a potential impedence mismatch between MailListener, ChainableMailListener, matchers and mailets (part of the mail listeners). I don't think that many people will use Maillisteners, rather they'll favor ChainableMailListeners. However, SOME people will. Remember, we're a solution framework as much as a mail server and not a single solution to a single problem or simple mail server (there are plenty of those).

      I'd like to get the idea flow flowing. Lets hear them. Please feedback and help me work out the details of this idea, ask questions, fight with me, etc. Also post your own RTs for other ideas we might proceed. Remember to put on your aspetos suit. We're all friends here but its important to fight through the ideas.

      Thanks,

      -Andy