[Mailman-Developers] New Feature Request: A Half-Moderator

[J C Lawrence]

On Tue, 2 Jan 2001 13:25:51 -0800 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> At 1:15 PM -0800 1/2/01, J C Lawrence wrote:
>> Percisely.  However we need to maintain the abstraction of
>> Mailman from its underlieing queue implementation,

> I wonder -- would it make more sense to suck all this back into
> mailman, and simply create widgets that export into MQS for things
> that are being distributed to it, the way we'd create a widget to
> hand a message off to the digester? what do we buy by not doing
> this? And is it worht the added complexity and overhead?

I don't see the gain by going this way, and I do see considerable
loss.  You are suggesting moving back from a fine-grained granular
system to a more monolithic/enclusive approach.  The normal
justifications for this are efficiency/performance (which doesn't
apply here as we're discussing areas which are not performance
bound) and ease of implementation (which is actually a false metric
as all you are really trading is effort at design time for effort at
implementation time) Monolithic seems simpler on the face of it
because you don't have to define your data flowpaths and
dependencies before hand and its easier to get away with fudging it
later without having to have thought through the whole problem
before hand.  Or, in translation: Its easier to hack as you go along
and to grow organically during development.

I don't see that as a viable or even valuable quality.  I also don't
like tools that have grown that way.

Yes, this can be handled with developer discipline, but that doen't
tend to be the way that projects grow -- and Mailman needs to get
beyond the point of Barry being the only one doing any heavy
lifting.  If we keep to the fine grained approach the componenets
will tend to be smaller and simpler and easier to design, write, and
debug.  We're going to have think more in the beginning to define
what the framework and data dependency models are -- that's a
classic tradeoff of where you spend your intelligence and brain
hurt: in the design or the in the implementation -- but the result
should be something which can then be easily extended in consistent
fashions (or hacked) without pain.

Or, to turn this around:

  I'd like to see Mailman become more of a mail handling/automation
  toolkit which happens to have a default example application for
  mailing lists.

If we go with the fine grained approach we should be able to do
*really* intereting things in v4.  Heck, done right we're talking
about defining a/the basic architecture for how scalable mail
processing/automation systems are built (remember those comments
about hooking a CRM tool off the side?).

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--