On 1/18/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
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 ;-)
I always have a hard time understanding what if any code could get shared. SMTP, POP3, IMAP are just as unrelated as HTTP and FTP, IMHO. All 5 protocols are geared towards a different purpose and require different optimizations, state management, etc... My 2 cents is that you've got two areas of code you might share: a) the literal protocol parsing layer, hopefully handled by 3rd party libraries like Jakarta commons stuff, and b) clearly defined examples of same behavior. For example, if moving a mail message into an IMAP folder could fire off a mailet (or a matcher/mailet combination) just SMTP delivering a message into a spool. That is a strawman idea, and I use it as an example of how I would approach any sharing of code... but whatever functionality the group agrees they want. +1 to Robert saying that you should embrace the protocol coupling to the store. I would put it even more broadly that use cases dictate everything, and that the protocol is just one expression of those use cases. The protocol parsing and storage to answer that protocol are further consistent expressions of those use cases. -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
