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

[Dave Klingler]

> At 9:50 AM -0700 1/2/01, Dave Klingler wrote:
> >This is a neat thread, because at this point (a big pile of queues) the
> >work needed to throw the whole thing into a database is trivial.  Chuq,
> >Apple's EOF would let you build a Mailman analog in under an hour, btw!
> >Faster and easier to maintain!
> 
> I was kinda thinking the same thing -- you start looking in terms of 
> messages and semaphores instead of a real queue manager. And instead 
> of moving messages among queues, you simply pass a token around from 
> place to place until mailman is done with it...
> 
> Doing this in a decent database becomes really interesting (in a fun 
> way, not in a grind your teeth way)

I wonder how easy it would be to do sort of a Mailman-lite that would sit
on top of PSQL or MySQL, although what you're talking about works nicely 
without a database until the message gets archived.   With EOF it would 
just sort of happen.

Huh.  Okay...how to pull out the various Mailman functions and expose them
so that some functions could be redirected to databases for big lists?

What if incoming messages were appended to single files that each represented
sort of a FIFO, with the filename/descriptor represented in a queue instance
description somewhere, something like the class in my previous mail?

Okay, then the various actions in the class could be filenames of executables
that would perform the various functions of that object.  THAT way, you could
easily change a particular function by changing the script filename, and the
script could be in any language, and could either be a call to a database or
something else.  Since everything's been abstracted and there are only a 
few list-types, you could easily keep an editable plaintext file that 
contained all your pseudo-class information.  Now you've got an extremely
flexible but very small group of scripts that fit together in an application
but can be easily maintained and replaced as needed, which is what someone
was talking about as a goal a few days back.

I'm not sure I explained that very well, but basically the idea is to take
the abstracted queue object structure I talked about before and just implement
each "class description" as a plaintext file that carries the names of the
executables that perform the various tasks.   There are only a few queues
anyway (other than the lists themselves) so it doesn't get messy in terms 
of the kinds of queues.  So maybe a list instance (directory) now looks 
like this:

Files in the Test List directory:
incomingMessages.queue
outgoingMessages.queue
requests.queue
config.db
description
various html files

That description file is just a plain text file that lists the executables 
that perform various functions for the list instance, inherited from the 
parent class "template", and if you want to do something different with
that list (like have partial owners, for instance) you can just "override" 
the names of the executables in the instance description.

What do you think of that rant?  Nothing like regular ol' textfiles for 
exposing the innards of a...er...program.

Dave Klingler