How to set up mailman 3
On [MM3-users] Mark Sapiro writes:
On 03/25/2017 04:55 PM, Mark Sapiro wrote:
A list's message_size can't currently be set in Postorius. File an issue at <https://gitlab.com/mailman/postorius/issues/new>.
Actually the attribute name is max_message_size, not message_size.
It exists in core and can be set, e.g., from the command line via 'mailman shell', but it needs to be exposed in Postorius.
Would it be possible to automate this? I haven't thought carefully about it, specifically security issues. However, there could (in theory) be an automated export of "all parameters" in "expert mode" or "site/list initialization mode".
Steve
On Mar 29, 2017, at 02:07 PM, Stephen J. Turnbull wrote:
Would it be possible to automate this? I haven't thought carefully about it, specifically security issues. However, there could (in theory) be an automated export of "all parameters" in "expert mode" or "site/list initialization mode".
It's probably near impossible to automate, because the Core's REST API isn't programmatically discoverable.
As a counter-example, Launchpad's REST API provides a WADL[1] description extracted from the code, but this makes it way too heavyweight for my tastes. And because the Core uses a dynamic object-based traversal system (inherited from restish and ported to falcon) it would make any kind of static REST API description pretty difficult to generate.
Cheers, -Barry
[1] https://en.wikipedia.org/wiki/Web_Application_Description_Language
Barry Warsaw writes:
On Mar 29, 2017, at 02:07 PM, Stephen J. Turnbull wrote:
Would it be possible to automate this? I haven't thought carefully about it, specifically security issues. However, there could (in theory) be an automated export of "all parameters" in "expert mode" or "site/list initialization mode".
It's probably near impossible to automate, because the Core's REST API isn't programmatically discoverable.
Right (I did know that). I was thinking "decorator".
As a counter-example, Launchpqad's REST API provides a WADL[1] description extracted from the code, but this makes it way too heavyweight for my tastes.
You have good taste, I'll grant that. ;-)
And because the Core uses a dynamic object-based traversal system (inherited from restish and ported to falcon) it would make any kind of static REST API description pretty difficult to generate.
OK.
Would you recommend against even exploring for a lightweight approach for some reason? Ie, the idea is bad according to some principle?
On Mar 30, 2017, at 12:57 PM, Stephen J. Turnbull wrote:
Would you recommend against even exploring for a lightweight approach for some reason? Ie, the idea is bad according to some principle?
To the contrary, I think if it were possible it would be pretty nice. In fact, you could conceivably eliminate mailman-client if you could do it, and other languages could auto-generate bindings to the REST API. I haven't kept up on the state of the art, but IIRC, there were Python libraries that could generate bindings based on WADL.
Cheers, -Barry
Barry Warsaw writes:
up on the state of the art, but IIRC, there were Python libraries that could generate bindings based on WADL.
That sounds cool, but I tend to feel that WADL gets pretty heavy. If we can't just mark things with something like "@exported_REST", it's not clear that the maintenance burden is worth it.
Steve
On 03/30/2017 08:01 PM, Stephen J. Turnbull wrote:
Barry Warsaw writes:
up on the state of the art, but IIRC, there were Python libraries that could generate bindings based on WADL.
That sounds cool, but I tend to feel that WADL gets pretty heavy. If we can't just mark things with something like "@exported_REST", it's not clear that the maintenance burden is worth it.
This would also go well with an idea I had about the current state of the REST API and encrypted lists. With having decorators like "@exported_REST", another one could get introduced, something like "@requires_permission("some.perm.name")" which would introduce permission-based granularity to the REST API. Then multiple user:password pairs could be specified in a config with different permissions and so Mailman could provide different levels of API access to different apps.
Although, reading Barry's message again, this may not be possible / maintainable.
-Jan
On Mar 30, 2017, at 09:45 PM, Jan Jancar wrote:
This would also go well with an idea I had about the current state of the REST API and encrypted lists. With having decorators like "@exported_REST", another one could get introduced, something like "@requires_permission("some.perm.name")" which would introduce permission-based granularity to the REST API. Then multiple user:password pairs could be specified in a config with different permissions and so Mailman could provide different levels of API access to different apps.
Our intention is to support permission based access to the REST API via an "authenticating proxy", which we call lemme:
https://gitlab.com/mailman/lemme/tree/master
and for an outline on how this might work:
https://gitlab.com/mailman/lemme/blob/master/OUTLINE.rst
We had good discussions about this at Pycon 2016, but haven't gotten very far in implementation details. I'm hoping we can spend a little bit of time on that this year.
Cheers, -Barry
On Mar 31, 2017, at 03:01 AM, Stephen J. Turnbull wrote:
That sounds cool, but I tend to feel that WADL gets pretty heavy. If we can't just mark things with something like "@exported_REST", it's not clear that the maintenance burden is worth it.
Agreed, but note this is only one half of the equation. You also need to publish the static definition of the REST API so that HTTP clients could discover it. That's my understanding of the role that WADL serves.
Cheers, -Barry
participants (3)
-
Barry Warsaw -
Jan Jancar -
Stephen J. Turnbull