[Systers-dev] Proposal to split dlist handler

[Anne Gunn]

Erica,

I'm glad to see that you are making good progress on this good idea.

The only comment I'd make is purely linguistic.  I think, when you implemented this idea, you just used the same terminology we used in our meeting with Simone.  It was useful as we fleshed out your idea but we did just make it up on the fly.

Reading your description below, however, it seems to me that it might be clearer long term if you called the split-up handlers something more like:

dlistPreProcessor or preProcessDlists
and
dlistPostProcessor or postProcessDlists

That terminology just seems more descriptive to me of what is really going on.  What we've always done is add a bit of dlist-specific postProcessing after all the mailmain handler processing is complete.  What you've identified is that we will a) be able to fix some known defects and b) have a bunch more flexibility moving forward if we also insert some of our code to preProcess emails before we hand them off to the standard Mailman handlers.

I'm not passionate about this but it is always simpler to get the terminology right before the initial checkin than any time later.

ag
--- robin at jeffries.org wrote:

From: Robin Jeffries <robin at jeffries.org>
To: Erica Wolfe <ericawolfe at gmail.com>
Cc: systers-dev+proposal at systers.org
Subject: Re: [Systers-dev] Proposal to split dlist handler
Date: Wed, 14 Jul 2010 22:22:09 -0700

I think putting all the utility functions into DlistUtils makes sense.

Yes, I've assumed that something like this was the solution to these bugs;
thanks for figuring out the details.

Robin

On Wed, Jul 14, 2010 at 12:21 PM, Erica Wolfe <ericawolfe at gmail.com> wrote:

> Hello all,
>
> I would like some feedback on a fix I propose.
>
> While researching a pair of unsubscription bugs, 386133 and 3244206, I was
> only able to reproduce 324406.  However, I was able to determine that the
> problems stem from running dlist unsubscribe emails through all the Mailman
> handlers.  Expanding on the patch proposed by beachbrake, splitting the
> dlist handler into two parts resolves the issues so I created an early
> dlist
> handler and a late dlist handler.  The early dlist handler contains only
> the
> code to unsubscribe from dlists but I chose a generic name as I expect that
> other folks may wont to put code in the file at some point as well.  The
> late dlist handler contains everything except the unsubscribe
> functionality.  In addition, I created a dlist handler util file but can
> put
> that code into Mailman/DlistUtils if that is deemed more appropriate.
>
> Does this seem logical and reasonable to folks?
>
> Regards,
> erica
>
>
> To unsubscribe from this conversation, send email to <
> systers-dev+proposal+unsubscribe at systers.org<systers-dev%2Bproposal%2Bunsubscribe at systers.org>>
> or visit <
> http://systers.org/mailman/options/systers-dev?override=144&preference=0>
> To contribute to this conversation, use your mailer's reply-all or
> reply-group command or send your message to
> systers-dev+proposal at systers.org <systers-dev%2Bproposal at systers.org>
> To start a new conversation, send email to <systers-dev+new at systers.org<systers-dev%2Bnew at systers.org>
> >
> To unsubscribe entirely from systers-dev, send email to <
> systers-dev-request at systers.org> with subject unsubscribe.
>


To unsubscribe from this conversation, send email to <systers-dev+proposal+unsubscribe at systers.org> or visit <http://systers.org/mailman/options/systers-dev?override=144&preference=0>
To contribute to this conversation, use your mailer's reply-all or reply-group command or send your message to systers-dev+proposal at systers.org
To start a new conversation, send email to <systers-dev+new at systers.org>
To unsubscribe entirely from systers-dev, send email to <systers-dev-request at systers.org> with subject unsubscribe.