Re: [Mailman-Developers] [GSoC 2014] Command line Client
Rajeev S writes:
The deliverables of the project would be, at the least,
- Command line tools to perform tasks in the mailman client docs
I think there should be one tool with multiple commands. These can be implemented by separate commands in a directory off the normal PATH if you like, or with annoyingly long names (a la git's scripting interface).
- Any Extra useful functionalities that can be identified, such as export, backup
- Other Useful tools like backup and restore.
- Man Page entries for the new commands
These look good to me. Also, a help command to display the man pages from the new tool.
Also, I did not quite get the "*coming up with a **great layout *" part. Do you mean to build a custom shell for mailman? If yes, what extra functionality should it provide than the standard command line tools?
I think that probably is what he means, but I personally don't think that's appropriate. If people want a "CLI with layout" (which I agree is plausible), what's wrong with Postorius via Lynx? (Florian?)
I suggest you should concentrate on the syntax of the command line, possibly building on the existing mailmanctl tool. (But let's check with Barry on that before you put in much effort!)
Steve
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/04/2014 10:49 AM, Stephen J. Turnbull wrote:
Rajeev S writes:
Also, I did not quite get the "*coming up with a **great layout *" part. Do you mean to build a custom shell for mailman? If yes, what extra functionality should it provide than the standard command line tools?
I think that probably is what he means, but I personally don't think that's appropriate. If people want a "CLI with layout" (which I agree is plausible), what's wrong with Postorius via Lynx? (Florian?)
No, that's not what I meant (using the term "layout" was obviously confusing - sorry for that!). I think we're talking about two possible, but very different concepts of a client here:
One is the one-off command (with options) that outputs a result,
either on stdout or saved to a file. This could make for an
interesting project, but I think then it would really make more sense
(like Steve said) to extend the existing mailman command instead of
writing a new one.
The other (and the one I had in mind) is a tool you invoke with a
commando which then offers a interface a little different from that of
your standard terminal shell (bash or else). Just like you invoke the
mysql/sqlite3 client (with a db name or file as option). What I meant
by "layout" is really the question what happens after one starts the
tool by typing something like $ mmclient --list=foo@bar.id" or $ mmclient --domain=python.org", not the actual visual representation.
Does that make more sense?
Florian
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTFvdqAAoJEEceGbPdavl76KIIAKLIsZEux/TPCSNV9sEQGJt1 s5gkIT298wZPPQfG+b2kllMO9o6uObQ0K10Ynk4yzLi1YngTyR1kC52Ty6uZ1pws YvD87o7DCeoZWDMss77+zvJkpkG+zFn4Ts3taeWW/9A1N9fJP22izgtm9aki+RLn 8nWn4jfTmnE3TvU8ptr/5uK0LPApfjMZz0mGCc6jgExdsJhVw11LU0Wzoxtw9424 1ygW2zWPcvdHTqykluvf62u24oTna641vNxE60LB9e4SF6LhS0Pi+F/w+m8zjNAT q3xY76yNlhZVI/N2cR4jinuUbagX61DSu7mgC4Kk08oyN6TgkS9kknlYrGupQ3c= =ufWT -----END PGP SIGNATURE-----
Thanks Florian. Things are much more clearer now.
I have built a basic command line version for the mailman.client, that will currently print the domain list and mailing list lists.
This is, as Steve mentioned, like the git interface
You can find it here
https://github.com/rajeevs1992/mailman-cli/blob/master/client*Usage:*
To list the registered domains in your server, do
- ./client domain --list
To list the registered mailing lists in your server, do
- ./client list --list
For help with options available, do
- ./client -h
*Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk <http://rajeevs.tk>*
On Wed, Mar 5, 2014 at 3:37 PM, Florian Fuchs <flo.fuchs@gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/04/2014 10:49 AM, Stephen J. Turnbull wrote:
Rajeev S writes:
Also, I did not quite get the "*coming up with a **great layout *" part. Do you mean to build a custom shell for mailman? If yes, what extra functionality should it provide than the standard command line tools?
I think that probably is what he means, but I personally don't think that's appropriate. If people want a "CLI with layout" (which I agree is plausible), what's wrong with Postorius via Lynx? (Florian?)
No, that's not what I meant (using the term "layout" was obviously confusing - sorry for that!). I think we're talking about two possible, but very different concepts of a client here:
One is the one-off command (with options) that outputs a result, either on stdout or saved to a file. This could make for an interesting project, but I think then it would really make more sense (like Steve said) to extend the existing
mailmancommand instead of writing a new one.The other (and the one I had in mind) is a tool you invoke with a commando which then offers a interface a little different from that of your standard terminal shell (bash or else). Just like you invoke the mysql/sqlite3 client (with a db name or file as option). What I meant by "layout" is really the question what happens after one starts the tool by typing something like
$ mmclient --list=foo@bar.id" or$ mmclient --domain=python.org", not the actual visual representation.Does that make more sense?
Florian
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTFvdqAAoJEEceGbPdavl76KIIAKLIsZEux/TPCSNV9sEQGJt1 s5gkIT298wZPPQfG+b2kllMO9o6uObQ0K10Ynk4yzLi1YngTyR1kC52Ty6uZ1pws YvD87o7DCeoZWDMss77+zvJkpkG+zFn4Ts3taeWW/9A1N9fJP22izgtm9aki+RLn 8nWn4jfTmnE3TvU8ptr/5uK0LPApfjMZz0mGCc6jgExdsJhVw11LU0Wzoxtw9424 1ygW2zWPcvdHTqykluvf62u24oTna641vNxE60LB9e4SF6LhS0Pi+F/w+m8zjNAT q3xY76yNlhZVI/N2cR4jinuUbagX61DSu7mgC4Kk08oyN6TgkS9kknlYrGupQ3c= =ufWT -----END PGP SIGNATURE-----
Florian Fuchs writes:
One is the one-off command (with options) that outputs a result, either on stdout or saved to a file. This could make for an interesting project, but I think then it would really make more sense (like Steve said) to extend the existing
mailmancommand instead of writing a new one.
Ah, I see. I think that what you're talking about, then, is deciding how much state to keep in configuration of the client, how much to require the user to enter, and whether to save state changes made during an interactive session.
For "stateless" commands like "status" (it reports the state, but issuing it is the same regardless of current state), or simple state- dependence (a "list lists on domain" command might be "mmclient list lists domain=python.org) you could do it as a shell command. For more complicated, state-dependent commands:
$ mmclient mm> status all qrunners running mm> set domain python.org mm> set list mailman-users mm> list members from list.org barry@list.org mm>
;-)
Then set of questions might be "should mmclient automatically save the settings for 'domain' and 'list'? Or should there be a 'save current settings' command? Or a special 'configure settings' command? Or should the user edit mmclient.ini?"
Is that the kind of thing you mean by layout?
participants (3)
-
Florian Fuchs -
Rajeev S -
Stephen J. Turnbull