-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Nov 7, 2008, at 5:25 AM, Andy Buckley wrote:
It sounds trivial, but one thing that I've always regarded as a
usability problem in MM2 is the proliferation of admin command
names. As
a terminal junky, a common way to learn the functionality of a
multi-purpose set of command line tools is to type their common prefix
and press tab to see what commands are available. In MM, there is no
common prefix, so this option isn't available and memory is needed to
remember the right command name... commands like 'newlist' and
'config_list' are spread higgledy-piggledy through name-space rather
than being neatly stacked in one corner. It would be great for
usability
if MM3 could use admin commands with e.g. a "mm-" prefix (with
installation of backwards compatible versions maybe as an option)
Andy, I feel exactly the same way! As Stephen points out, the
tradition in Mailman has been to separate Mailman's command name space
into its own 'bin' directory, which at least helps reduce the command
line pollution.
An alternative approach, used most prominently by Trac, is to have a
single admin command which can either behave like a non-interactive
process or a subcommand interpreter, depending on how it is called. I
would be happy to spend some time on a mm-admin command, using the
same
Python "cmd" module as trac-admin if there is the interest. This might
also involve moving some of the intelligence out of the admin scripts
and into the API, which is also good news for people like me who
have a
need/desire to hook MM into a wider system management framework.
Mailman 3 definitely takes this approach, aided in large part by
setuptools. Ideally, there should be little but option parsing shim
in the command modules, but even there, with setuptools, we're able to
move everything into the mailman.bin package so at least it's /
feasible/ to import it and use it. The code in the mailman.bin
modules are not always organized in a convenient way though. I have a
strong desire to change that (there should be no unique logic in a
mailman.bin module).
I like the idea of a master command, and quite naturally I would
choose 'mailman'. I didn't know that Trac did this, but lots of other
programs do, and I would look at the Bazaar code to see if there's
anything we can steal there too. If there's a Cheeseshop package we
can just use, all the better.
Now that Python 2.6 is out, and 3.0 nearly so, I'm hoping to shift
most of my free hacking time back to Mailman 3. All help with the
command reorganization would be welcome.
Another thing to think about is bringing sanity to the command line
options. Those are about as inconsistent as you can get too, though
MM3 tries to bring some sanity back there. For example, some commands
take a -l option to specify the list name they operate on, others use
a required positional argument. Blech.
PS. I'm also interested in taking a look at MM3 templating... is this
being actively worked on or did it stall after the GSoC effort?
It's not being actively worked on, but I'd like it to be.
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkkV1uAACgkQ2YZpQepbvXE19wCfVgqBWpah2Yeft9SDk9vs0qoe
p2MAnA6udvrP8mm6eak6TjZOI9Ui5Jf8
=2HOW
-----END PGP SIGNATURE-----
_______________________________________________
Mailman-Developers mailing list
[email protected]
http://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:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
