On 10/05/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Danny Angus wrote:
> > I would propose an alternative architecture for James (not the mailet > > API yet) which looks like this.. > > I am feeling a bit snarky at the moment, but did you and the others who > replied, happen to read the REST of my e-mail, or just the first part? Guilty as charged. I did but it didn't register as I was obsessing about the first bit. Sorry it was both disrespectful and unprofessional of me. > Everyone developed tunnel vision on the in-process processor, and not one of > you commented on the protocol handler chain, which had already addressed > every one of your concerns. To repeat, with emphasis: Ok, I'll address it this time.. > "The *OTHER* of the *TWO* things I want to discuss is a change to how the > SMTP handler is structured. I want to suggest a chained approach, although > I'm not entirely sure of which of a couple directions would be best. Still with you ;-) > > The code currently in the handler that pulls and parses messages would be > factored out. The code that it dispatches to would be formalized in an > interface for the protocol handler. Yes we're still at the same party... > Each event: connection, HELO, MAIL > FROM, RCPT TO, etc. would have a corresponding method in the protocol > specific interface. Extrapolate this to its logical conclusion, have the protocol contain a Map of Command object delegates, and select the delegate based upon the command itself as the key. > Our code would implement that interface, but so would > fast-fail filters. I'm proposing that the filters, i'd called them rules, would be called by the command handlers, using the event listener pattern. > The outside loop, either MINA based or socket-based, > would take the each complete command and dispatch it to the chain, at which > point either the container would iterate over the handler chain, or we would > use a doNext type approach. This would give us a nice pluggable > architecture for fast-fail on a per-event basis." > > I even laid out how this fits in with Mike Heath's work on MINA, and how we > can accommodate the use of *either* MINA or the current socket-based code. > > The in-protocol processor and protocol handler chain are complementary > solutions. Not arguing anymore! In summary I still think the in-process-processor is a bit hard to swallow probably but this is probaly my fault because I don't understand the requirement.I also think that the fast fail requirement should be satisfied by a wholly assembled approach to protocols, towards which your proposal goes some way, but not as far as I would go. d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
