'''HOW DLIST WAS IMPLEMENTED IN MAILMAN'''
The various changes you see below are those that have been included in Mailman version -2.1.10.
''' 1. In mm_cfg.py''', we add:
- A Dlist Queue (Queue/DlistRunner.py)
In global pipeline we insert Dlist handler before CookHeaders. (Mailman/Handlers/Dlists.py)
For Dlists to work every new conversation is explicitly started by sending mail to 'listname+new@domainname' or 'listname+new+subject@domainname' if subscriber wants to explicitly define the subject/thread name.
2. '''PostgreSQL Database:'''
To deal with the *new* threads or conversations, Systers have added a database in PostgreSQL. Each list has its own database containing information about who is subscribed to what conversation and with which other aliases can a subscriber send emails and still be allowed to post to a list.
See : http://systers.org/systers-dev/doku.php/systers_database_in_postgresql for more details on database schema.
All the database interactions are handled by mailman/Mailman/DlistUtils.py file and we have provided STORM Orm support for it.
When the message is handled by the Dlist Handler, we do our thing - parse the subject for “new” or thread name, and then call functions in DlistUtils depending on what the command was.
DlistUtils's newThread() and continueThread() do the database stuff. Now if you are thinking that why have a whole another Queue for Dlists? The reason is that the Incoming pipeline is handling *one* message (one set of recipients & one msg text). For Dlists, we actually want two slightly different messages and disjoint sets of recipients(one who have subscribed to new conversations and others who have either unsubscribed from new conversation or have explicitly unsubscribed from an ongoing conversation) to be created from the one original message. The original message is sent to nobody (except the archives), while two new altered messages are inserted into the Dlist queue.
- The Dlist queue doesn't do anything except put the msgs in the outgoing queue.
Mailman 2.1.10 kept its info in .pck files.Dlists require the database. We have to keep the database in sync with new members, and option changes made via the web. Dlist changes MailList.py to use the DlistMemberships class instead of OldStyleMemberships class to handle member changes. DlistMemberships inherits from OldStyleMemberships, so the changes in DlistMemberships.py are usually a) do something additional we need to do for Dlists, then b) call the parent method to do the non-Dlist-related work.
'''3. Other Visible changes'''
The listinfo page where users can subscribe to a list has a different list email address for dlists, which is given on the page. For dlists as well as for non dlists the creator of the list can chose to activate the essay feature, which is not in the standard Mailman.
Footer of emails
In the emails sent out via a dlist, the footer is changed to give information on different features of the dlist. For instance, users can unsubscribe from a single conversation if they wish to, instead of unsubscribing from the entire list. The footer is (for dlists) stored in the mlist object and included by /usr/local/mailman/Handlers/Decorate.py. All mlist objects have the same footer.
To the options page, Systers has added the possibility to add different aliases with whom the subscriber can send emails to the list. This feature is called “other incoming address” and is handled through the postgreSQL database.