Danny Angus wrote:
> > Two items I want to run by the list.
>
> > In-Protocol processor for SMTP handler:
> I don't like this, sorry mate, because (pls read all of this, it is
> *constructive*):
> 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?
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:
"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.
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. Each event: connection, HELO, MAIL
FROM, RCPT TO, etc. would have a corresponding method in the protocol
specific interface. Our code would implement that interface, but so would
fast-fail filters. 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.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
