[Mailman-Developers] [GSoC] Encrypted mailing lists

[Stephen J. Turnbull]

Hi Jan!

Congratulations on being selected!

Note that Mailman is a PSF suborg, so you have to comply with PSF
reporting standards.  I'll get back to you if you need to do anything
more.  The only thing I can think of offhand is to register with the
PSF "planet" (or whatever they're using to aggregate blog posts).  I
*think* that's not even ready yet (or maybe they set it up today).

My apologies for disappearing on you after the application period,
it's been very busy for me (most of my teaching responsibilities are
in spring term, April-June, and startup is alway demanding).

A few comments on the content.

Jan Jancar writes:

 > ### Current state
 > 
 > Relevant mailman-developers thread from GSoC 2015:
 > https://mail.python.org/pipermail/mailman-developers/2015-March/024477.html
 > 
 > Example plugin:

Thanks for the summary.  I was wondering what people meant by "plugin",
now I know!  (I wouldn't call this a "plug-in architecture" to be
honest; I'll be interested to study your improvements.)

 > ### Proposed changes
 > 
 >  * Add configuration option similar to config.styles.paths to
 >    Handlers, Rules, Chains etc.. Which Mailman will use to look
 >    for components, so that plugins can just be accessible on the
 >    python path and not necessarily inside the Mailman package.

Not enough, IMO.

 >    Or use just one path per plugin and a standardized plugin
 >    structure:

Yes, more structure, please.

 >  * Let plugins add Pipelines the same way they can add Handlers etc...

OK.

 >  * Let plugins subscribe to receive events.

OK.

 >  * Let List creator specify List Style when creating it through
 >    Postorius.

AFAIK this is already an RFE.

 >  * Allow multiple callables in pre_hook and post_hook run
 >    in order specified.

Seems reasonable, you'll need to talk to Barry about that.  (Of course
you can always implement this with a hook-managing hook function.  So
it's a matter of abackward compatibility.

Steve