I get that but still think that implementing escapes to other languages might look better via a mailet.
I find these languages mainly useful because (in addition to being easier to edit than XML IMO), it provides flow control that our LinearProcessor does not, e.g., local variables, if/else blocks, and complex conditional expressions.
Running this as a mailet instead makes these languages an *alternative* to using mailets for email processing. I'm not necessarily opposed to this, and that might be useful in situations such as per-user scripts.
All you would have to do would be to invoke the seive mailet and point it at an external sieve script. Otherwise we do what? pollute the config files with any number of different scripting language code snippets (yuk) or blur the line between internal (to the Mailet context) workflow and invoked external processes.
For the situation you describe, I think it would be best if we went with one and used that in the default configuration. We could still allow others as options, leaving it to the admin if he/she wanted homogeneous or a mix of languages.
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
