Danny Angus wrote:
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
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.
IMHO "handlerapi" should not be smtp specific: we use handler for every
protocol. Maybe someone doesn't share this view, but I thought this was
the main intent in calling "handler api". At least the pattern (if not
the code) can be (and IMHO should be) reused between protocols.
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.
Well, I've not been the author of the current 2.3 fastfail, nor of the
trunk handlerapi, nor of the handlerapi-v2 branches. I believe there was
some consensus about a need for new code there. I simply worked on some
stuff related in handlerapi-experiment (that is the Nth experiment).
No one told that handlerapi-experiment is more valid than what anyone
else want to propose, but I think that a newcomer should know what code
is already present and written before trying to force new
ideas/patterns. That's all.
As I already specified I will explain my ideas, and I currently probably
don't understand Robert ideas, because I don't see any
performance/design improvements in the application of that patterns, so
I'm here to understand and be sure that if I understand the
performance/extensibility improvement I will be happy to "rm -rf
handlerapi-experiment" !
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".
Danny, of course this is "my own view", I started the sentence with
"Personally". Everyone should write his own idea to understand what is
the group idea.
Btw I don't think this discussion will bring anywhere: please take a
look at the code, at what robert is proposing and let's talk of concrete
things: it is always easier to cast a +1/-1 on code than on abstract
ideas. (I understand it is a limit of mine to not understand what Robert
is proposing, so feel free to ignore my comments if everyone else is
understanding his proposal).
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.
Ok, but we should try to be more concrete :-)
Thank you for joining the thread.
Stefano
PS: I don't understand why this thread seems a me against robert or
danny. I'm simply trying to understand robert ideas, and to ask him
explanations. I did this with Joachim when he provided the current IMAP
code, and he didn't take my questions/critics as a personal attack or as
"my rules" against him. Did I write something bad? If my message was
hard I ask sorry to anyone offended, but I'm simply trying to *get*
*more* from a new committer (Robert).
I have not big interests in this discussion. I replied because I thought
Robert's ideas deserve an answer, but If anyone else from the PMC will
take care to interact with Robert about his proposals I will be happy to
shut up and simply oversight.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
