Norman Maurer wrote:
2) Split currently provided command handlers into multiple command
handlers: the current handler already support multiple handlers per
command, it simply stop after the first handler writing something as
response.
Yes that seems a good point. So we can write "diffrent Handler plugins"
per cmd! That is a very good point cause we can move some checks thats
optional to new handlers which will us allow to add new features without
touching the "mainHandlers" .
The multiple commands are already supported this way. The proposal is
simply to "split" che current commands.
Btw I already seen that if we don't implement an "hook"/"event"
mechanism we'll soon have too much handlers per command that will work
only in the given sequence and for a single feature we'll need to write
more than a handler.
The ideal flexibility (my goal :-) ) would be to have one new handler
for each "new feature" and not a bunch of handlers for each feature.
3) Add an init(SMTPSession session) method to the CmdHandler interface:
implementing this method handlers could add informations to the session
when initialized and, for example, the EHLO handler could add ESMTP
extension headers based on data wrote in SMTPSession.state by the single
CmdHandlers.
Can you explain a bit more? is that like the
session.getState().put(object) method ?
In its init the DataCmdHandler could add information to the sessions to
tell that it supports the ESMTP SIZE extension. The MailCmdHandler could
add informations about the support of the ESMTP AUTH extension. The
EhloCmdHandler could read this informations and write the correct
response automatically.
This would be a perfect scenario for extension points and plugin ala
eclipse, but we should move one step at a time.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
