> > I am thinking that we could have a JellyProcessor, e.g., > > <processor name="custom-stuff" > > class="org.apache.james.transport.JellyProcessor"> > > ... > > </processor> > > allowing the script to handle its own matching and > > functionality.
> I'm not sure that we need to force Jelly, or any other scripting language to > operate in a discrete processor. Doing so would mean that the processor > could not invoke standard or scripted mailets and matchers without making > special provision. Reuse would be lost. Only within that processor. That should not be a problem. We can still have your ScriptedMatcher and ScriptedMailet, too, but there are some cases (sieve comes to mind) where the semantic matches up better as a processor than a matcher/mailet model. > ??? sieve ??? Sieve. CMU. RFC 3028. See: http://www.ietf.org/rfc/rfc3028.txt http://asg.web.cmu.edu/cyrus/sieve/ also lots of projects on SourceForge I don't know of any Java implementation of Sieve (RFC 3028) as yet. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
