Danny Angus wrote: > Lots!
Danny, I agree that where we are simply introducing support for expressing conditional logic and evaluation in a scripted language, that this is best done within the current Mailet container, so as to continue leveraging the existing declarative mail flow. I don't see the advantage of creating a new container just to get the language support for matchers, which seems to be part of what you are suggesting, if I understand you correctly. An alternative approach is used in the currently submitted ScriptedMatcher and ScriptedMailet, which support any BSF language. The particular language used by each Matcher and Mailet is specified in the 'language=' tag of its declaration. Thus, in one processor, multiple languages can be 'mixed and matched'. We could subclass to avoid the 'language=' tag and have 'JavaScriptMatcher', 'JPythonMailet', etc. A new container makes sense for something like Sieve, which implements its own mail flow. It has no need of, and it would be difficult to inter-operate with, individual Mailets. So, there is no point it carrying the overhead. A Sieve container would be James aware and we would declare Tests (like Matchers) and Commands (like Mailets) to Sieve which under the covers may exploit James facilities to do their work. Administrator written Sieve code would use these blissfully unware that it was running in James and the developer of this code would only have to understand the Sieve process flow, not that of James. Cheers, Steve - - - - - - - - - - - - - - - - - - This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may not represent the views of Synergy Systems Limited. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with "received in error" as the subject and then delete it from your mailbox. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
