Hi Barry!
On 06/10/2017 05:19 AM, Barry Warsaw wrote:
Hi Jan,
I haven't had a chance to look at the MRs yet, as it's my first week at a new job. But I have to say that your descriptions below look really great; I'm impressed at how well your design fits in with Mailman overall, and how clearly you've described them. I'm not sure I could have come up with anything better!
That's great to hear! Thank you and best of luck at your new job.
I have just a few questions, though we can hash out specifics on the MRs.
On Jun 08, 2017, at 12:45 AM, Jan Jancar wrote:
Add plugin infrastructure
This MR is the biggest one and certainly the most important one for the pgpmailman plugin and other potential Mailman plugins. It adds a notion of a plugin to Mailman Core. To explain what I mean by a plugin, it's best to look at its example configuration:
[plugin.example] path: example_plugin class: example_plugin.plugin.ExamplePlugin
I'm curious as to why you define both a
pathand aclass, where the latter has the former as the first component. I'm not making a judgment (and haven't looked at the branch yet), so I'm just wondering what led you to this decision.
I wanted the possibility of configuration, where for example the plugin
package might have more IPlugin classes with different behavior and so
the site admin might choose the plugin class he wants to use (a kind of
plugin super-package). Or really just to not force the plugin creator
to put the plugin class in some specific path with relation to the
general plugin path which is used for loading components as the plugin
class is a specific kind of component (only one per plugin).
It might be fine to just drop the class part, load it in a similar way
as other components (so it will be in the .plugin subpackage of the
plugin package) and just enforce that one plugin entry in config can
provide only one IPlugin implementation.
Mailing list styles currently have an attribute for name, which for the default styles is:
legacy-announce legacy-defaultWhich is not particularly human-readable, well it is, but doesn't look like something to be shown in a web ui such as Postorius. Mapping these style names to their descriptions in Postorius is possible, however since the styles are dynamically found and instantiated, it's not something practically doable.
So this MR adds a description attribute to IStyle and adds the appropriate descriptions to the default styles. Also exposes said description to REST clients.
Have you thought about how these descriptions will be internationalized? We'll clearly want to present style descriptions in the natural language of the admins who are creating new lists with a particular style.
Hmm haven't thought about it yet, as I thought it was quite similar to attributes of other Mailman's components, however this is indeed different as it's not shown only to site admins but list admins / through Postorius. Will see what's possible there.
Cheers,
Jan
/\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ #