On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>> I think this is a step back from the current design or it simply regards
>> something we already trying to solve differently with the handlerapi.
>
> the current API design is flawed: this is just one way to fix it.
Let me better approach this discussion: what is your knowledge of the
whole james code (in particular the smtpserver/handler), how it changed
in 2.3.0, how it changed in trunk, then in the 2 experimental branches
and now in the handlerapi-experiment?
The handler api may or may not be OK for SMTP, but there is no reason
at all why it should be suitable for any other protocol because it was
designed to allow flexibility in the configuration of SMTP in general
and fast fail in particular.
I haven't seen *any* designs or design dicussions which talk about
change to the handler api apart from your experiment. There is no
reason why your experiment is any more valid than Roberts proposals.
Personally I value a good set of working code much more than any
discussion about messaging api vs method/interface oriented (OOP) api.
Thats is only your view but remember that there are many of us who
would rather have a designed solution which takes all the requirements
into consideration and builds upon solid OOA/OOD principles than "the
first thing that works".
I think our main layers are
1) Protocol handling
2) Message processing
3) Message storage
+1
Most of the Joachim work is about the message storage.
Most of the protocol handling code, imho, can be made common between our
line based protocols (using the command pattern and maybe the memento
for the session, like you propose).
Initially I thought this thread was about 3, while your diagrams seems
to me about 1: this is why I'm confused.
There does seem to be a mix of the two responsibilities. But that
isn't necessarily an issue with the design it may be that all that is
needed is for the names to be made more generic (remove the word IMAP)
and we would see how this design provides a POP/IMAP compliment to the
SMTP handler api.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
