[Mailman3-dev] Flexible data storage

Dale Newfield Dale at Newfield.org
Mon Mar 15 15:50:05 EST 2004

On Mon, 15 Mar 2004, Kevin McCann wrote:
> I envision a MM3 which can both a) focus on message delivery and
> *nothing* more, and b) be flexible with regard to data storage,
> including archives, all depending on the need.  Those who want to
> deliver mail and nothing more can do just that. So be it. And those who
> want to develop exciting. community building tools can do so, too, using
> MM3.

The questions of "who defines what nouns (tables) exist," "who defines how
those nouns (tables) translate into mailing lists," and "who manages the
nouns (rows in tables)" are critical here.  If MM is to function, it
clearly needs to expect to be able to determine some nouns and manage
them.  It isn't necessarily *the* repository, though.  While MM3 bolted
onto XYZ community system will need to be able to know something about
"subscribers," that community system probably already defines a
"user/member" table, and the questions above become paramount.

I suggest we build this thing in a modular manner, letting it be realized
in configurable fashions.  An example I keep going back to is for a
school.  They likely already have in place something that says "these
students exist" and "these classes exist" and crossover tables that say
"this student is in this class".  Why not be able to set up one list-type
as "class-list".  It would require adding a "list-configuration" foreign
key either for the entire list-type or per-class, and it would require
adding a "subscription" foreign key to the crossover table.  It would
require somehow storing per-subscriber (instead of per-subscription) info
in either the student table directly, or maybe a foreign key.  This would
enable the "student" table to exist within the app, the "subscriber" table
to exist within MM3 and linkages between them.  I've attempted to write
about this in a general way several times before and feel I've never
succeeded well.  This is why I'm looking forward to the sprint.


While there's plenty of complexity here, it's all in managing the
pipeline.  The things moving through it are bags of bits and while those
bags may have internal structure, handling them as anything more than bags
of bits is really out of scope.  We've got plenty of complexity without
trying to come up with yet another way to store structured email
headers/body/attachments/etc. in a DB in a queryable manner.

Dale Newfield <Dale at Newfield.org>

"They that can give up essential liberty to obtain a little safety deserve
neither liberty nor safety." - Benjamin Franklin, on the Statue of Liberty

More information about the Mailman3-Dev mailing list