[Mailman-Developers] Another big batch of checkins coming

[Barry A. Warsaw]

I have another big batch of changes that are about to be checked in,
and I wanted to give CVSers a heads up that there might be a bit of
instability as all the commits go through.  I promise to get back to
the raging GET vs. POST debates after this "branch" is merged.

The changes that are coming grew out of some discussions Dan Pierson
of Control.com and I had at the 9th Python conference earlier this
year.  The features were fairly high on Control.com's wish list, and I
felt that these features and changes were good for Mailman.
Control.com funded some focussed work in these areas and the results
of those efforts are what I'm going to be checking in.  I want to
thank Control.com, and especially Dan and Ken Crater for their
support!  From my perspective this kind of sponsorship was very
successful, and could serve as a model for others willing to fund some
Mailman development work <hint> <hint>. :)

There are three general features that are being added.  A brief
overview follows:

    - a topic filter
    - membership adaptors
    - "virtual" mailing lists

Topic filters allow a mailing list admininstrator to define topics,
based on regular expressions, that list members can use to filter out
some portion of a list's traffic.  Topic matching is performed on the
Subject: and Keywords: headers (with optional extension into message
bodies).  Individual users can select the topics they are interested
in and will only receive message that match those topics.  Topic
filtering only works for regular delivery; topics have no effect on
digests.

Membership adaptors will allow a mailing list to get its membership
information from any external source.  Essentially, it's an API for
accessing and changing all information related to a list's subscriber.
The API was inspired in part by Chris Ryan's Datasource Implementation
Template (see the Mailman wiki), although it only covers membership
information (similar to Chris's MemberData class), and the API
reflects my own design preferences.  There is currently only one
implemented adaptor: OldStyleMemberships which use all the traditional
data structures in the MailList object.  I've played with adaptors
that can extract membership information from flat files, and have
toyed with a ZODB based membership adaptor, but neither of those are
ready for prime time yet, so I won't be checking them in.

[Aside: although not sponsored directly by Control.com, the membership
adaptors made it easy to add support for Real Names, so that will be
part of the check too.]

[Aside: additional ancillary changes allow MailList instance
customizations via an extension framework.  Also, the web GUI
parts of the admin interface are being further componentized for
easier customization.]

Finally, there will be support for "virtual" mailing lists.
Essentially, you create a normal list, but there are now two external
interfaces which allow you to send a message to an explicit set of
recipients, who need not be members of the list.  The message to that
set of members will look like it's coming from the real mailng list.
The two interfaces are 1) a Python module you could import from your
application, through which you could call Post.inject() with a message
object, a list name, and a list of recipient email address; 2) a
command line interface which an external process could call to pass
the same information to Post.inject().

Enjoy,
-Barry