I'm not adversely disposed to relaxing this but I'd like to know why we'd choose a processor over a mailet for the role.
A language like Sieve, which is now an RFC, has its own notion of matching, flow, and operation. As Steve pointed out, we could wrap all of that in a Mailet (using the All matcher), but that seems kind of odd.
However we do it, I believe that supporting other mail filtering languages, such as sieve, as-is will be a valued capability.
Sieve would be nice if there is the impression that other people are familiar with it. That said, I'm not sure there really is.
My idea was to take Jython (and I guess something similar is done with BSF) to create our own scripting framework. We continue to use mailets and matchers by exposing them to the script. The configuration for such a processor would be a) the location of the script file (or inline it) and b) a list of mailets and matchers with their configuration info.
The hardest part for these scripting solutions is addressing processor forking. When you get a partial recipient match in a matcher, Linear Processor handles cloning the message and dividing the recipient list. I'm not sure how any of these BSF/Jelly/Jython solutions could handle that.
And just to step back, I think it would be much better to have any of these solutions access existing mailets, not shove these into a mailet so it's an entirely separate approach to message processing. Sure, allow the scripting language to do a lot of the basics that we've had to code as mailets or matchers, but have the basis as wrapping our existing mailet API.
-- 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]
