[Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
Stephen J. Turnbull
stephen at xemacs.org
Sat Apr 26 10:29:27 CEST 2014
Rajeev S writes:
> Hi Abhilash,
Please don't top-post. It's very helpful to readers to keep the
"subthreads" about particular issues separate, while at the same time
bundling them together for ease of mail-handling.
> I did not quite get the user role part.A command line utility runs on the
> server on which a software instance runs, just like a MySQL command line
> utility.You will need physical access to the system or atleast the shell.I
> believe you cannot expect every moderator of the list to have that kind of
> access. From my point of view, the tool will be used by the list owner or
> the server admin, just like the MySQL shell,which can be used only if you
> have access to system shell.However, User/Role management can be imposed by
> including a login for the shell,if necessary.Again,that's not possible for
> the command tools.
Why not? The CLI tools will have access to the user database, so in
theory you could authenticate. In *practice*, this may be outside of
the scope of your project because there's no provision for
authentication in the current RESTful interface; you end up
restricting to connections from localhost.
But by the same token, past projects have decided to connect to
Postorius rather than Mailman itself precisely because Postorious
*does* maintain roles and credentials for users. Again, probably
beyond the scope of your project, but for precisely this reason it has
been proposed a few times that the authn/authz part of Postorius be
broken out into a separate module.
> And Yes.Users will be a part of this. I prefer to build the other two
> first.Many methods that can come under User class is better suited under
> the other two.For eg, for adding a moderator to the list, you can do, *list
> --addmoderator user_id , *which should be under the List class*. *But the
> same from user point of view, would be a complicated and less intuitive
> command, *user **user_id **--addmoderator **--list list_id *. So, after the
> list and domain functions are built, It will be more clear what the user
> class must do.
I agree with your logic here.
But I find the text very difficult to read. There should be at least
one space after a sentence-ending period ("Yes.Users" looks like a
class attribute!) And I have no idea what the semantics of "*" is
intended to be.
> About optparse, I actually meant argparse,sorry about that :). And thanks
> for the style guide tip.
Despite the current thread on python-dev<wink target="Barry"/>, I
strongly recommend the pep8.py tool (available on PyPI as well as
upstream: https://github.com/jcrocholl/pep8/). pyflakes, pylint, and
pychecker are also good tools, but their orientation is a bit
different, and you may or may not find them useful (and in particular
you may find after a while that you *never* get warnings from them).
More information about the Mailman-Developers