[prev] [thread] [next] [lurker] [Date index for 2002/08/26]
On Sun, Aug 25, 2002 at 02:38:46PM +0100, Simon Wistow wrote:
> Do we want lots of little utilities -
>
> % siesta-new-list foo
> % siesta-new-user simon
> % siesta-add-users-to-list foo simon richardc gem
>
> (or something)
>
> or one utility with lots of options
>
> % siesta new list foo
I'm thinking I like the latter more, but then I prefer cvs to arch
too. siesta is a taken name already (it's the name of the top-level
module and the project, and I don't want a third way for it to clash)
so I'm suggesting poncho or sombrero, or something of someone else's
choosing.
This is some initial doc work for what I'd like to see.
=head1 NAME
poncho - administer siesta mailing lists
=head1 SYNOPSIS
poncho [-C configfile] $command args
=head1 DESCRIPTION
configfile holds defaults such as hostname, path to aliases file, mta
type, path to archives, paths to datafiles
=head2 COMMANDS
=over
=item init [-type={DBI,DBM,...} [$type_args]]
initialise a new database, possibly outputting a ready-canned version
of tequila that points at the right db
=item newlist $listname
create a new mailing list, if possibly editing the correct aliases
file (this would be nifty)
=item load $listname
=item dump $listname
Output/load the list configuration from text files
=item adduser [--notify] $list USERS
=item removeuser [--notify] $list USERS
if no users are supplied then read a list from stdin
=back
Possibly there would want to be specific add/remove plugin commands,
but that's a bit up in the air I guess.
I'm now going to spend a quick 30 minutes or so (until 6' under)
separating Class::DBI related stuff from user stuff, by sticking it in
a Storage subclass.
--
Richard Clamp <richardc@xxxxxxxxx.xxx>
Generated at 13:56 on 01 Jul 2004 by mariachi 0.52