"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