Danny Angus schrieb: > 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
I think our goal is to share as most handler-api code as possible. So why we should not try to create an handler-api which fit all needs (POP3,IMAP,SMTP....) ? In SMTP it is called fastfail but there are also needs for plugin "hooks" in POP3 or other protocols. For the POP-Before-SMTP stuff. I modifed the core POP3 handler in trunk to let it work. With a pluggable hook api i had manage this by hook in the right code ;-) > . > > > >> 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. > > bye Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
