...

...

...

...

"JR" == John Read <john.read@newnet-marketing.de> writes:

JR> I have a suggestion how this can be done very easily. If the
JR> function maketext (in Utils) had an addition parameter "list",
JR> it could first try to open the text file in
JR> mailman/list/"listname"/"lang". If the file is not there, then
JR> it could continue to take it from /mailman/templates/"lang" as
JR> you have coded it. This would mean that if the list manager
JR> wanted to put special messages in a list he can create them in
JR> the list/"listname"/"lang"/....... directory. The normal list
JR> manager would not notice any difference.

That sounds like a good idea.

JR> I have another question. In the v2.1 expected functions, you
JR> have listed the function to enter the full name. This leads
JR> onto a completely new set of possibilities with links into
JR> databases, and personalised mailings, etc. I can imagine that
JR> all these possibilities are too complex to fit into one
JR> program (mailman), but what about an simple API where the
JR> completed email (with associated data) could be presented to
JR> another application for further processing, eg filling fields
JR> in the email from a db. Applications could then designed
JR> separately by other groups, and slotted in required by the
JR> list managers.

Here's how I would envision that. Let's say you had a list for which you wanted to do some extra prep work on messages before they were sent out. You would write a module for the Handlers directory which performed this prep work. This module would hid all the communication with the external service.

Next, you'd figure out where in the normal message pipeline you want your special module to go. Now you have two choices:

• you can add your module to the global pipeline, and only perform the work when you see a message destined for one of your special lists (the MailList object gets passed as a parameter to your module's process() function).

• you can specialize your list's pipeline to include your new module. In 2.1 the main processing qrunner (IncomingRunner) looks in three places for a pipeline to process the message on: the message's metadata (used primarily for requeued messages), the MailList object's `pipeline' attribute, then the global pipeline.

  There probably won't be a convenient API for setting the list's pipeline at first, but it would be trivial to write a withlist script to add it.

Make sense?

-Barry