On 1/18/07, Danny Angus <[EMAIL PROTECTED]> wrote:
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 don't think our goal should be to share the code, it should be to
create correct, good, implementations and reuse code only where it is
appropriate. Just because POP & IMAP bear a passing resemblance to
SMTP it is not necessarily true that a detailed analysis of the
requirements for each one will result in a common requirement. For
instance at the most trivial level SMTP is about decision making and
accepting messages whereas POP is about retrieving them I don't know
that this makes a difference but it *might* and until we have done the
analysis we have to be open to that possibility.
one of the tricky points about IMAP is that reasonable performance
requires that commands be executed in parallel but there are complex
rules that must be applied to the scheduling. to support concurrent
access to the same mailbox by multiple clients requires understanding
of all commands that all clients wish to scheduled against that
mailbox. this suggests to me that the scheduler cannot be associated
with a single handler.
given that a mailbox may (in james) may support multiple protocols, i
cannot see clearly how this could be done without a single multiple
protocol schedule per mailbox.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
