[Mailman-Developers] about qrunner and locking

[Chuq Von Rospach]

At 6:48 PM -0800 12/8/00, J C Lawrence wrote:

>There's a danger here of assuming that everything is a Python shaped
>nail.  I have misgivings over making a Pythonic wrapper that
>consumes the entire membership resource versus a callout that
>returns the membership base view requested by whatever means the
>installer provides.

On the other hand, look at where the sponsorship of Mailman is coming 
from, and because of that, I don't have a huge problem with it -- but 
to some degree that implies mostly that we design an API that can by 
default use Python (mumbles), but allow syou to write a python glue 
set to some other (mumble) if you want. I think making as much of the 
*default* configuration python is a very good idea, as long as you 
allow for the ability of users to replace those default pieces with 
more sophisticated (or different) pieces if you want. I ahve this 
terrible nightmare of coming out the other side of 3.0 where the 
INSTALL document opens with "first, download these 17 things from 
freshmeat and install them. you can now start configuring Mailman..."

Don't take that to imply entirely self-contained, just that reacing 
out to outside code has to be carefully considered and well thought 
out. it's stupid to re-invent the MTA or Apache, for instance. it 
looks (from discussions today) that it'd be silly NOT to integrate 
queue mangement stuff (aka, "suck in cron") into Mailman.

>I don't like over-arching APIs.

Maybe we shouldn't be using the term API here, because what I think 
we're talking about are to some degree class objects. And if you 
think of it in terms of OOP, you may have an over-arching object 
(class "mail list manager"), but that gives you the opportunity to 
override subclasses to do what you want -- and ONLY have to rewrite 
those pieces you need accomplish what you want. The concept of an API 
for "subscriber database" seems overwhelming, but if you have a class 
for that, if it's done right, redoing the subclass that interfaces 
with the outside store and switching from zdb to dbi/mysql shouldn't 
be too significant.

I think I'm arguing semantics here, because I think we're using the 
term API to more or less the same definition as class definitions in 
OOP, but it might help us to think about this if we look at it in 
classes architecturally.

>I have the feeling that with a little thought we could break the
>base design of Mailman down into a finely grained granular mesh of
>single purpose tools.  Then changing the basic setup simply means
>replacing one of the base tools with some other simple tool that
>generates the same type of output from different resources.

Hear hear. I wish I'd said that.

Here's something to chew on, just because it bubbled up out of the 
muck and seems worthy of metioning. In all this talk of 2.1 and 3.0, 
of zope database stores and my site-wide subscriber beastie, and 
multiple-machine send queues and thelike, I'm wondering if we're 
maybe starting to define a thing that reaches beyond the needs and 
capabilities of the small site. So as we move forward, maybe we need 
to keep in our mind the issues of "mailman light" versus "mailman 
robusto". this ties in nicely I think with what JC is bringing up, 
and would help us test the robustness of the APIs/classes - there be 
a baseline Mailman (mailman light) with basic reasonable 
functionality, and plug-in replacements with more functionality where 
we want to move towards the robusto version. For instance, we might 
not want to use zdb for the light version, but some simpler but 
endemic format (like marshalls) -- but you lose performance, you lose 
NFS locking, and other features a small site won't need anyway -- but 
you don't need to install lots of other stufff to get running.

And if you think in terms of that, then 2.1 is the 
bugfix/easy-upgrade release, and then perhaps 2.5 is where all of 
those interfaces get defined and mailman-light is implemented, and 
3.0 is where robusto is implemented to supplement the light. It would 
give us the ability to build parallel development teams for robusto 
and light (or for modules within each) down the road, and keep us 
honest in terms of the APIs, because if we cheat on an API, we break 
one or the other...

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

We're visiting the relatives. Cover us.