I hadn't time to install majordomo 1.94 yet but what we need is a library
(say a Majordomo.pm module) which one could reuse to build other
interfaces on top of it. In particular WWW interfaces or others.
Feedback is welcome.
On 22 Oct 1996, Jason L Tibbitts III wrote:
> This is pretty long; there's design stuff towards the end so if you're at
> all interested in development you might want to skim through.
>
> >>>>> "DB" == Dave Barr <barr@math.psu.edu> writes:
>
> DB> I for one think that TLB should be integrated with Majordomo.
>
> I am not completely certain that putting _all_ of TLB into Majordomo is
> what people would want. It does a bit too much and it isn't small.
> Unfortunately, Majordomo talks SMTP itself you lose the ability to use an
> external batcher like TLB or bulk_mailer.
>
> OK, how about making several modules and letting the Majordomo owner at the
> site decide which to use? Anyway, that's more of an implementation detail.
>
> DB> Perhaps we should start divergent source trees here and offer only bug
> DB> fixes for 1.94 (1.95, etc) but start integrating TLB and the config
> DB> file dump stuff now for 2.0beta tree?
>
> I dislike the idea of diverging the trees because it can be a real pain of
> both trees are changing with some rapidity. On the other hand, if one
> branch is only getting small fixes it isn't a problem.
>
> DB> Diverging source trees works well for the Linux kernel and others.
>
> Actually Linus really doesn't like to do it; witness the agonizing over the
> decision to branch 2.1. You really want to wait as long as possible before
> you can branch.
>
> I suppose the real question centers around just what we want 1.95 to be.
> We really should decide this, but perhaps we need to wait and see just how
> 1.94 fares. We've been talking about a lot of minor features that people
> want, but with the code in its current state there's only a couple of
> people with the intestinal fortitude to actually add them.
>
> Here's what I _wanted_ to do with the guts of 1.95:
>
> Take out all of the commands (do_*) from majordomo and move them into
> mj_cmds.pl or somesuch.
>
> Remove deflist handling from each command and make it separate, so you call
> commands that can take the default list as:
> do_subscribe(deflist_munge_args(@parts));
>
> Remove list handling code from all commands and put it in mj_list.pl. The
> idea is that you have one subroutine, add_address_to_file or something
> which takes care of all of the locking issues and such. The same goes for
> removing an address, checking for the presence of an address, etc. This
> makes it really easy to have a command that, say, removes a user form the
> main list and puts them on the digest list (or the nomail list) or adds a
> secondary allowed address for a poster (for restrict_post checks) or
> whatever.
>
> I decided to stop there. This isn't really all that much work, and the
> mj_list.pl stuff lets you write a quick command line subscribe-unsubscribe
> tool (which acts as a nice proof of concept).
>
> When I actually got into this, though, I found that I kept wanting to do
> more. I wrote up some documentation on how I might want the command
> processing engine to work. I tried to come up with something where you
> could write a command and tell the system what kind of arguments it needs
> and have it work without having to rewrite the top-level interface. In
> other words, the email interface would know how to deal with it and could
> put it automatically in a help file, while the Web interface would know
> what kind of buttons to put up and such. Here's a set of rough notes I
> took. Keep in mind that I was still thinking perl4 compatibility (i.e. get
> this into 1.95) then. I'm not now, as I understand that this should be 2.0
> stuff. Please feel free to comment; I'm not attached to any of this.
>
> - J<
>
> --------------------
> Internal interface:
>
> Have a list of commands that are legal.
>
> For each command, have of argument_checking function names, a list of
> pre-functions and a list of post_functions.
>
> The args need to be well defined, so an interface can tell what is required
> and parse arguments, put up buttons, whatever.
>
> For each function, a (faked) list of parameters:
>
> @legal_commands = ("subscribe", "list_name\001email_address");
> # subscribe takes a list_name and an email_address.
>
> Arguments are checked by a function like:
> valid_list_name
> valid_email_address
>
> Perhaps there could be additional structures that define exactly what kind
> of data is expected for each (string, switch, password); this could be
> useful for a web, tk, or curses interface.
>
> A big problem is commands that take variable numbers of arguments. One way
> is to allow unchecked arguments, which are just passed on. Another is to
> allow a list of alternates. (For perl4 compatability separate alternates
> by \002, for perl5 only, use a list of lists.)
>
> Another problem is commands that eat the rest of the file as input, like
> newconfig. Provide for this with an "argument", multi_line, which would
> tell the email interface to eat te rest of the input and perhaps tell
> another interface to open a multiline text entry widget.
>
> Additional lists, pre_COMMAND and post_COMMAND, contain names of functions
> that should be executed before and after COMMAND is executed. They will
> receive the same argument list that COMMAND receives; that is, the user
> input will have been pre-munged by the interface code into the proper form
> (if necessary). OR: should these be allowed to modify the arguments in
> some way? This way you could do deflist munging with a pre_command.
>
> Remember that the internal interface doesn't get to use the filehandles
> that the external interface has (it might not be running on the same
> machine), so it just can't assume it can read stuff from the incoming email
> itself.
>
> Internal interface functions are not things like "lock_file" or
> "add_address_to_file", they are things lile "subscribe" and "index".
>
>
> External interface, email:
>
> Break down into functions and args as we currently do.
> Check for valid_command, if not, complain.
>
> Check arguments. Stuff them in an array, call check_arguments. Note that
> we may have to supply the list name _if_ we allow a default. This is the
> job of the external interface, not the internal one because the internal
> subscribe doesn't care about default lists.
>
> Thie means that valid_list_name will (probably) get called multiple times
> by the email list to see if a list name was provided. Tough.
>
>
> Calling conventions for internal interface functions:
>
> Each internal interface function of course takes the arguments it requires.
> The address should be one string, not a whole pile of separate strings. It
> returns a list containing a numeric return code and a string (possibly
> multi-line) which explains the result.
>
> The numeric return should be 0 for failure, positive for success and
> negative for tentative success (authorization required, for example).
>
> The string returned should properly explain what has happened:
>
> "Subscribe to list $list_name succeeded."
>
> "Your request to $whoami:\n
> \n
> $command $list_name $email_address\n
> \n
> must be authenticated. [...]"
>
> This string should be appropriate for all interfaces.
>
>
>
> %legal_commands = (
> subscribe, "list_name\001email_address",
> unsubscribe, "list_name\001email_address",
> signoff, "list_name\001email_address",
> cancel, "list_name\001email_address",
> passwd, "list_name\001passwd\001string",
> which, "string",
> who, "list_name",
> info, "list_name",
> newinfo, "list_name\001passwd\001multi_line",
> intro, "list_name",
> newintro, "list_name\001passwd\001multi_line",
> config, "list_name\001passwd",
> newconfig, "list_name\001passwd\001multi_line",
> writeconfig, "list_name\001passwd",
> mkdigest, "list_name\001passwd\002list_name\001string\001passwd",
> lists, "",
> help, "",
> get, "list_name\001archive_file",
> index, "list_name",
> auth, "auth_key\001command\001unchecked",
> );
>
> # approve is probably a special case in that it's only useful for the email
> # interface. Other interfaces will have different methods of authorizing
> # admin stuff. This is an example of how an interface can add its own
> # commands.
> # Aargh, no way to easily append to a hash!
> %legal_commands = (
> %legal_commands,
> "approve", "passwd\001command\001unchecked"
> )
>
>
------------------------------------------------------------
Arnaud Taddei tel : +41 22 767 9349
CN Division 513 1-019 fax : +41 22 767 7155
CERN mail: Arnaud.Taddei@cern.ch
CH-1211 Geneve 23 URL: http://wwwcn.cern.ch/~taddei
------------------------------------------------------------
Follow-Ups:
References:
|
|
