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

    RT: Ideas to take from JAMES and Mail Scripting

    acoliver

      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

        • 1. Re: RT: Ideas to take from JAMES and Mail Scripting

          Have you heard of Groovy? Apparently it's a newer Java-based scripting language that doesn't have the funkiness of Jython syntax. Javascript would be adequate I think. Probably more "admin" friendly.

          WWMCSED? What would MCSEs do? ;-)

          Hit my blog here: Links for Andy's links all together in linkable form.

          Steve

          • 2. Re: RT: Ideas to take from JAMES and Mail Scripting

            I like the idea of a mail solutions framework. Until you get the Exchange functionality going that will probably be the bread and butter.

            • 3. Re: RT: Ideas to take from JAMES and Mail Scripting
              acoliver

              "Until you get" -- and I thought you were planning to be one of us? Membership in the us is low, just send real good code :-)

              • 4. Re: RT: Ideas to take from JAMES and Mail Scripting
                acoliver

                As you said, JavaScript is probably adequate for the task and more admin friendly. It may be possible to support multiple scripting languages provided they support limiting their domain. Meaning I only want you to script what I expose to you nothing more. JavaScript (aka ECMA) is probably a must if we intend for admins/power-admins to be able to write things like matchers.

                • 5. Re: RT: Ideas to take from JAMES and Mail Scripting

                  ""Until you get" -- and I thought you were planning to be one of us? Membership in the us is low, just send real good code :-)"

                  I'm just trying to be humble and not make any assumptions about anything. I want to help where I can. Why do you think there aren't that many people in the U.S.? You'd think some of the hotter Java weenies would be available. I definitely don't count myself among them. Maybe in 5 years.

                  Steve

                  • 6. Re: RT: Ideas to take from JAMES and Mail Scripting

                    http://theserverside.com/blogs/showblog.tss?id=SpringVelocityEmail

                    Did you see this? I think something like that would be killer. E-mail templates should be very useful. We don't use Spring at work, or Velocity for that matter, but I hate our sections of code that are like

                    if (fail) {
                    // Big nasty JavaMail mess
                    }

                    Even for mass mailouts on certain events, it'd be much cleaner that way.

                    • 7. Re: RT: Ideas to take from JAMES and Mail Scripting
                      acoliver

                      If you build it they will come. You'll find that as the project becomes more functional recruiting will go up. The velocity email templates look okay on the JavaMail side, but still looks a little ugly if you ask me. Not sure what I prefer. I'll have to ponder it. Velocity seems ideal for mail merge templates but maybe something even simpler like JavaScript setting of properties and a simple ${blabla} on a text or html page. I suppose once you start doing ifs and loops you're probably at velocity anyhow.... I guess I just wish velocity had chosen to escape with something else other than the # which occurs more frequently in mails...But its definitely an idea. The template part.. the Spring/XML part looks like some nasty plumbing to me.

                      • 8. Re: RT: Ideas to take from JAMES and Mail Scripting

                        "If you build it they will come." I agree.

                        I'll take a second look at it, to see what we might want to do. I don't use Spring or Velocity currently. A long time ago I used WebMacro, when servlets first came out, but I haven't used that in ages.

                        Maybe we need some sort of combined approach, or something. I don't really want to use a big nasty XSLT transformation engine type thing.

                        Steve

                        • 9. Re: RT: Ideas to take from JAMES and Mail Scripting
                          acoliver

                           

                          "spiritualmechanic" wrote:
                          I don't really want to use a big nasty XSLT transformation engine type thing.


                          You said it! Yuck-eee. Any templating solution should be easy as pie. This should plug in with mail scripting/matchers/mailets I think. Of course first we really need mail list support.