james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Future direction for James
Date Fri, 14 Nov 2003 22:03:20 GMT
> > 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message