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.
A year ago, sieve wasn't an IETF RFC, and there were maybe two sieve related projects on SourceForge, one of which was CMU libsieve. Things have changed, although I think we'd still be ahead of the curve. We were, and still are, ahead of the curve with Bayesian filtering.
Eh, check again. Sieve: RFC 3028, January 2001. http://www.cyrusoft.com/sieve/ Granted there are more implementations since it was issued almost 3 years ago, but still.
That said, reviewing the site made me realize I must be on a low-traffic Sieve-extensions or some impl's mailing list. The actual sieve mailing list is pretty active.
So you would use the scripting language to implement more complex logic, and still use Matchers and Mailets as conditional/functional components respectively. That sounds like it would fit in with the idea that Steve had about adding scripting to the existing processor model, although I still believe that such a scripting processor is different from LinearProcessor.
Yes, a different processor. Mailets would get exposed to the script as Sieve extensions (actions), or as Java objects in BSF/Jython (not sure about Jelly).
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 am not sure if they would or not either. I think that most uses of a scripting system would be all or nothing. But these scripting systems allow us to extend the object model, so we could provide tools to allow them more control. That would certainly be necessary to implement your concept, above.
I see how you could restrict it, but it seems like it would be really nice to carve off recipients to a mailing list and proceed that way. Maybe you do just have these scripts work when you need all-or-none behavior, typically when first received or heading into a mailbox/on the way out.
So, I see mailets as pretty easy to expose, but matchers hard. Perhaps let matchers get exposed, but block any partial mapping. The processors could take matchers, put a wrapper around them, and check and prevent partial matching.
That could be a nice idea. And it would help keep scripting users from going too far off, and away from matchers and mailets.
I was thinking for user scripts, you can configure a handful of mailets (and matchers if we can expose them) that are always there to reference in the script. Like in sieve you have reject, fileinto, redirect, keep, and discard. Maybe have mailets called log, sendasim, etc...
-- 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]
