[Mailman-Developers] [GSoC] Encrypted mailing lists - update v4

[Jan Jancar]

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
/__\/__\  #

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20170610/600d2212/attachment.sig>