[Mailman3-dev] Flexible data storage

[Barry Warsaw]

On Mon, 2004-03-15 at 16:22, Erez Zadok wrote:

> I suspect that over the coming weeks, we'll easily get into genuine
> disagreements over the scope of the work.  One person's vision and desire
> for certain features may easily conflict with another's.  A total rewrite of
> such an important package comes once is a long time (and I applaud Mailman's
> maintainers for having the guts and foresight to take on such a big task).

Some would say we're insane and delusional. :)

> I'm sure no one would want to have to rewrite Mailman yet again.  Any good
> software package has to accommodate its own evolution through flexible
> EXTENSIBILITY mechanisms (i.e., hooks and published APIs).  I think the
> design of MM3 should be such that it will have a good deal of decoupled
> modules that "talk" to each other using well-established and flexible APIs.
> We have a rare opportunity to create a design that'd last for many years.

I totally agree.  I'm thinking of Mailman 3 more as a library or a
framework than an application.  Of course, only a small number of
hackers will care about that, and we need to keep in mind that we're
going to distribute something useful.  Which means that there will be
default implementations of most of the APIs.  Having a turnkey list
manager that's at least as easy and featureful as MM2 is a high
priority.

> - It should be easy, for example, for anyone to replace the current
>   plaintext storage subsystem with an SQL backend.

+1

> - I should be able to easily define a chain of pre-processing filters (e.g.,
>   spamc) to get a hold of the message before MM does.

+0, mostly because we have to tease out where the boundary between the
MTA and the MLM is going to be.  For example, a virus detector probably
belongs in the MTA long before Mailman sees the message.  A spam
detector /might/ belong in the MTA, but clearly Mailman wants to do some
classification of messages before it hits the list membership.

> - Similarly, post-processing hooks: what if I want to pipe each message to
>   PGP or some other crypto tool before it's saved on disk.

+1

> - even the management API could be decoupled from the current HTML one.
>   What if I wanted to write a GNOME or SNMP API to manage mailman?

Or Cocoa <wink>.  +1

> - Imagine that with a pre-subscription hook, I could ask for someone to
>   input their PGP public key.  Then, with a compatible hook just before
>   sending a message to a subscriber, I could sign the message with the key.
>   I'm not sure if this is a feature that we want to put in MM3 from the very
>   beginning, but the *hooks* should be there.

+1

-Barry