ADK
Danny Angus wrote:
Ok, I just re-read your original.
My opinion is now that you either do use mailets or you don't.
Obviously a 1/2 and 1/2 approach is going to be the worst of both worlds.
What I'd also say is why not try to use a mailet approach. I say this because we're trying to get the mailet API enhanced to support more sophisticated behaviour, and you have a test case of more sophisticated behaviour.
What we're about to offer, that is relevant, is
a) Mail properties. Matchers and mailets will be able to set and get serializable persistent properties on Mail objects they handle. This allows mailets to work step-wise with Mail exhibiting state.
b) Matcher parameters, enhanced matcher config provided by elevating match from attribute to element in the config.
c) Matcher chains, initially AND (only no OR) matcher chains will pass the mail through the configured matchers and only mail which passes all matchers will reach the mailet.
d) Configurable processor classes. Its my desire, now that the Mailet contract so closely resembles the Processor contract, to see processors added to the API, so that developers can add new processors other than the standard LinearProcessor. This will allow people to support FIFO pipelines, or forking pipelines and other more sophisticated or specialised pipelines.
I hope that this covers all of your requirements, I believe that it does. :-)
d.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
