[Mailman3-dev] Flexible data storage

[Erez Zadok]

In message <Pine.OSX.4.58.0403151400130.9129 at bambi-newfield-org.local>, Dale Newfield writes:
> On Mon, 15 Mar 2004, Kevin McCann wrote:
> > - list config
> > - member information
> > - message archives
> 
> A mailing list package is a tool for distributing messages.  It is the
> pipeline through which messages pass.  As such it should be described by
> the pipeline, not by the items passing through it.  While I agree two of
> the most basic concepts in the system are lists and subscribers, I am
> completely unconvinced that this system should contain the messages
> passing through it once the tool has done it's job.  This is not a message
> repository--if it is, then what you want is usenet, or yahoo groups, or
> some other tool.  You are welcome to build a new yahoo groups, and I will
> be glad to shape the mailman design in such a way that it can be a useful
> tool to help you do just that.  I don't, however, want mailman to *be*
> that tool.  I want it to do well that which it does, and in a highly
> configurable manner so it can be utilized in *many* larger systems.

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).

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.

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

- 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.

- 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.

- 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?

- 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.

With a highly-flexible design, we would find that many people will
contribute extensions and modules for MM3; and commercial vendors will be
very happy too (I surmise from the IP discussions that Barry wants to keep
the GPL but also accommodate commercial uses of MM w/o the usual restrictions
of the GPL -- the ever more popular dual-mode license).

Cheers,
Erez.