[Mailman-Developers] Re: Components and pluggablility

[Barry A. Warsaw]

>>>>> "JCL" == J C Lawrence <claw@kanga.nu> writes:

  | 1) inbound            Message arrives at the MLM
  | 2) authentication     Do I accept it?
  | 3) moderation         Does the list accept it?

Remind me again about the difference between 2 and 3, and why 2 is
under the purview of the MLM.

  | 4) pending            Associate a distribution list with message
  | 5) outbound           Send it.
  | 5) bounce             Demote the subscriber
  | 7) command            A combo of #2, #3, and command processing.

I'm not totally sold that 4 needs a process boundary, or that 2, 3,
and 4 aren't part of the same process, structured as interfaces in the
framework.

> So in my view, when Mailman decides that a message can be
> delivered to a membership list, it's dropped fully formed in an
> outbound queue.  

    JCL> Not exactly.  It drops a mesasge, any relevant meta data, and
    JCL> a distribution list in the outbound queue.  A delivery
    JCL> process then takes that and does what it will with them (eg
    JCL> VERP, application of templates, etc).

In Mailman 2.0 the distribution list is also metadata -- it lives in
the .db file.  Do you see that differently?

> [Side note.  Here's another reason why I'm keen on ZODB/ZEO as the
> underlying persistency mechanism for internal Mailman data: I
> believe we can parallelize the moderate-and-munge part of message
> processing.  Because the ZEO protocols serialize writes at commit
> time, you could have multiple moderate-and-munge processes running
> on a server farm and guarantee db consistency across them.  

    JCL> There are problems with this due to the fact that external
    JCL> transactions (such as SMTP sends) are asynchonous and not
    JCL> nested in ZODB transactions.

But I see the smtp sends as being in a separate process, i.e. the
outbound qrunner.  The easiest way I see of getting smtp hard failures
back into Mailman is simply to craft an internal message and drop it
in the bounce queue.

> These processes are not completely independent of Mailman though,
> e.g. for handling hard errors at smtp transaction time or URL
> generation for summary digests.  Some of these can be handled by
> re-injection into the message queues (i.e. generate a bounce
> message and stick it in the bounce queue), but some may need an
> rpc interface.

    JCL> Thus the pending queue above -- it allows a mesasge to
    JCL> undergo a set of pre-post filters prior to landing in the
    JCL> outbound queue. Archiving, digests, all sorts of things can
    JCL> happen at that point.

Maybe I'm taking the term "distribution list" too narrowly in your
description about.  Do you "list of recipient addresses" or do you
mean "internal queue routing destinations", or something else?

-Barry