I agree with you. Here are my thots - For instance to implement an SPF handler - that verifies sender in MAIL Command and later point in time wants to add a header to the message that SPF check is passed. Currently a handler can implements both CommandHandler and MessageHandler interfaces and protocol handler chain just maintains Message handlers and Command handlers. Any CommandHandler can trigger message handlers if it sets Mail Object. That is contract between SMTPSession and Handlers
With the design you are proposing, the protocol chain handler needs to be aware of a Command handler called DATACommandHandler since it has to associate the message handlers to DataCommandHandler. Is my understanding correct or am I missing something? Naren -----Original Message----- From: Stefano Bagnara [mailto:[EMAIL PROTECTED] Sent: Friday, April 21, 2006 7:18 PM To: James Developers List Subject: Re: Fast-fail / Handlerchain change proposal Venkataraman, Narendra wrote: > Regarding moving message handler code to DATACmdHandler code would > make the architecture inflexible, if somebody wants to develop their > own Custom Datahandler and still reuse some of the message handlers. Well, now you can overwrite the DataCmdHandler with a DataCmdHandler that is not compatible with the current DataCmdHandler and break that onMessage stuff. In fact we have SMTPHandler code that work only if the DataCmdHandler do something specific (set a message in the session). This seems like a "weak" contract and I like much more to remove that dependency by moving the MessageHandler handling to the DataCmdHandler. MessageHandler is IMHO a further layer build on top of the "low level" protocol handler chain. If we move that to the default DataCmdHandler then you can extends the default DataCmdHandler if you want to keep the MessageHandler/onMessage support, or write your own custom handler with no support of MessageHandlers, as you prefer. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
