[Mailman-Developers] about qrunner and locking

[J C Lawrence]

On Fri, 8 Dec 2000 18:16:51 -0500 
Barry A Warsaw <barry@digicool.com> wrote:

>>>>>> "JCL" == J C Lawrence <claw@kanga.nu> writes:

JCL> I argue similarly.  To echo you Chuq, a primary goal should be
JCL> ability to integrate.  That't given I'm increasingly coming to
JCL> question the use of Python pickles in the first place, let
JCL> alone use of custom database implementations.  I don't see that
JCL> the value is there for the increased complexity and isolation
JCL> of the system.  We already have enough problems given the fact
JCL> that that the membership base is kept in a pickle that I don't
JCL> see much reason to go further down that rat hole.  Yes, pickles
JCL> are nice -- for private data that will never be seen or
JCL> accessed by an external system.

> I completely agree that keeping the list database in marshals (not
> pickles, actually) is broken.  

Oops.  My bad.

> The question is what to do about it.

I think we have to bite the bullet and make an architectual rhange
and not try and do bolt ons that continue the current business.  We
need to classify the persistant data into management sets, define
access policies for those sets, and then provide abstracted
interfaces for them.  (any more buzzwords I missed?)

For example there appear to be five basic data sets that Mailman is
concerned with:

  Inbound mail
  Outbound mail
  Global MLM configurations
  List configurations
  User account configurations

The queueing improvements we've recently discussed would seem to
handle the first two reasonably well, and certainly don't seem to
commit Mailman to a design choice that will be expensive later.

The last one is the really interesting one.  Not just because users
want the ability to have membership lists be entirely dynamic, but
because the same abstractions we use for user accounts are likely to
be applicable to the other two.

I'm now going to kick back with a good beer, crank up Tubular Bells,
and think about this for a bit.

> So the real advantage of using ZODB is that it's very friendly to
> Python programs, and should provide the right kind of framework
> for plugging in all kinds of backend database sources.

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.

I don't like over-arching APIs.  I do like small self contained and
well constrained tools that assemble in useful fashions.  Or, if you
wish, I'd rather take a Postfix-ish view of a multitude of
cooperating single-purpose tools in a defined framkework, rather
than a sendmail-ish one-thing-does-everything-with-plugins approach.

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.

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