Hi Danny, This all sounds very good! Since am almost 70% done with my implementation including a handler for DSN style bounce messages and an Example DBProcessor. I would suggest that I complete an initial prototype (Non mailet/matcher approach) including rolling my own config and then I submit my code somewhere for others to review. (This should help back some requirements with a concrete example)
One reason for this is that I guess it will still be a little while before the new Mailet API is usable. As the new Mailet API starts to develop we can start migrating my code to the new mailet/matcher API with the enhanced features and maybe discover some other requirements. Other points: 1. Did we come to a conclusion on how to handle DB connections in Mailets? Is the mailet responsable, is the MailetContext going to provide for this or is it optional based on the MailetContext implementation? Thanks, Sergei ----- Original Message ----- From: "Danny Angus" <[EMAIL PROTECTED]> To: "James Developers List" <[EMAIL PROTECTED]> Sent: Monday, January 27, 2003 3:25 PM Subject: RE: Mailet Configuration 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]>
