> I believe that adding Jelly support to the current Mailet
> container is a better route than creating a new container.
Why? The current container knows, or will know when some code is moved out
of JamesSpoolManager, how to initialize its matchers and mailets from its
own XML configuration element. Its behavior is to initialize and manage
matchers and mailets. It has some specialized code in it for ensuring that
when we get to the end of the chain, there is code there to handle the "fall
off" condition.
The Jelly Script Processor's behavior would be different. There would be a
script. The script would implement its own flow depending upon the actual
scripting technology used. It would not necesarily have the same sort of
collection-based branching used by a Mailet processor. The Jelly Script
processor might want to cache the message's state upon entrance, and either
GHOST or ERROR a message whose state did not change.
> A Jelly script can benefit from the state management support
> built in to the LinearProcessor.
If so, we factor out that sort of behavior, and make sure that the Jelly
Script processor has suitable state management support for working with
Jelly Scripts.
> Conversley, Sieve would be an excellent canidate for a container as it
> defines its own state management.
Agreed.
> Still, what is the real value that a Sieve container brings? Sieve suport
> would make James configuration more administrator friendly, a major area
of
> concern for many.
As-is support of an IETF standard for common mail behavior where the full
power of James' custom matcher/mailet solutions are not necessary.
> Of course, we would need a Java implementation of Sieve first!
I am not aware of one, unfortunately. Do I hear "org.apache.james.sieve"
from anyone? :-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
