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 >> ------------------------- >> [mailman!288](https://gitlab.com/mailman/mailman/merge_requests/288) >> >> 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 `path` and a `class`, 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-default >> >> Which 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 /__\/__\ #
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
