Hi all.
Currently still looking into what changes will be necessary in core in order to cleanly implement encrypted mailing lists as a plugin, so this is my second status report. I will start doing these pretty much weekly now, and definitely weekly/ more frequent when the coding period starts.
All of my reports (currently only this one) can be found on: https://neuromancer.sk/ https://neuromancer.sk/recent.atom
(https://neuromancer.sk/article/2)
Also pasting it here for clarity and replies:
## Plugin API enhancements in Core
To cleanly implement encrypted mailing lists as a plugin to Mailman Core I propose several general changes to the plugin api, to allow for cleaner integration of plugins, more flexibility and easier plugin deployment. First I present the current state of pluggability in Mailman core and then present the proposed changes.
### Current state
Relevant mailman-developers thread from GSoC 2015: https://mail.python.org/pipermail/mailman-developers/2015-March/024477.html
Example plugin: http://threebean.org/blog/plugins-for-mailman3/
A plugin creator has many ways of "injecting" his code to run at certain phases of Mailman's operation, since Mailman looks for its classes and components dynamically, it doesn't care whether they are from a plugin or originally from core.
Implementing IHandler, IChain, IRule, IEmailCommand, ICLISubCommand or IStyle and placing modules containing the classes in the appropriate directories where Mailman finds them and instantiates them.
Implementing IRunner and adding the custom runner to mailman.cfg.
Implementing IArchiver and adding the custom archiver to mailman.cfg.
Implementing IMailTransportAgentLifecycle and setting the custom MTA in mailman.cfg.
Setting a custom callable in pre_hook or post_hook (only one callable per hook).
Core config variable ext_dir is unused.
There is not much documentation / examples of plugin creation, however core is very well documented so it's just a matter of figuring out what's pluggable or not.
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. Or use just one path per plugin and a standardized plugin structure:
- plugin package
- handlers
- rules
- chains
- commands
- pipelines
- styles
- plugin package
Let plugins add Pipelines the same way they can add Handlers etc...
This means refactoring BasePipeline, OwnerPipeline, PostingPipeline, VirginPipeline from mailman.core.pipelines.py into a package mailman.pipelines
Use find_components
Let plugins subscribe to receive events.
Let List creator specify List Style when creating it through Postorius.
Allow multiple callables in pre_hook and post_hook run in order specified.
Drop ext_dir.
Cheers,
Jan
/\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ #