And verily didst John P. Rouillard spake of these matters:
> >jr How about
> >jr
> >jr ($list, $sender, @parts) =
> >jr $pre_command{$key}($list, $sender, @parts) if defined ...;
> . $sender is the envelope sender btw.
> function to call). However, do remove $list, since you are right,
> there is no way to know what list is being subscribed to with the
> current majordomo (I have an extention that looks at a -l command line
> flag to majordomo when using majordomo at the -request address sorry
> for the confusion).
Ok, now the $list and $sender make sense: not as values already
parsed from the parameters, but as pre-existing context. For what it
is worth, the current majordomo subroutines get these values as
global variables and not as parameters, so I don't see much harm in
not passing them as explicit parameters to the new routines either.
> Not that I am assiging @parts as well as passing @parts. The
> pre-command can change anything it wants.
I think the return value of the pre_ subroutine needs to be an
error flag that stops execution of the primary command subroutine
if the error flag is set. Therefore we are back to passing @parts
by pointer. I don't think that's really a problem, though.
> If "pre_get" wants to set
> new values for the get command it can easily. Yes it will have to
> parse the input values, but it would have to anyway
Yes, agreed.
> Given that $pre_command{"get"} = &pre_get, why wouldn't the following
> change requests for "get bblisa-help 1" to "get bblisa 1"??
In general your example is very much what I had in mind.
> if defined ($pre_command{$key}) {
> $simple_pre_command_scalar = $pre_command{$key};
> ($sender, @parts) = $simple_pre_command_scalar($sender, @parts);
> }
As I mentioned, the return value should be an error code which decides
whether to continue or not. Here's something of what I was thinking:
$fail = 0;
$pre_command_subroutine = $pre_command{$key};
if (defined (&$pre_command_subroutine)) {
$pre_failed = &$pre_command_subroutine(*parts);
}
if ($pre_failed) {
&squawk("$key failed."); # this line may be redundant.
} else {
# call sub and post_sub
}
Which is mostly the same, plus the error check.
> # evaluate do_get etc.
> [...]
>
> <in another file far far away, but still eval'ed>
> $pre_command{"get"} = "main'pre_get";
We might not even need to explicitly specify this. I'm thinking that
my recently-posted patch for automatic command recognition from
subroutine names could very simply add a check for the existence of
a pre_ and post_ subroutine in addition to the current check for do_
subroutines. Just define a subroutine called "pre_get" and it will
be found automatically.
> sub main'pre_get {
> local($sender,@parts);
>
> # oops bblisa-help mailing list is obsolete. It has been superceeded
> # by the bblisa list (I think parts[0] is the list name right?)
> $parts[0] = "bblisa" if ($parts[0] eq "bblisa-help");
>
> return($sender, @parts);
> }
This is exactly the sort of thing that I think a "pre_" subroutine
is good for. Also continuing the "bblisa" example:
sub main'pre_subscribe {
local(*parts) = @_;
# get $subscriber from @parts and/or $reply_to
# get $clean_list from $parts[1]
....
if ($subscriber =~ /local.domain/ &&
$clean_list eq "outside") {
$parts[1] = "inside";
}
if ($subscriber !~ /local.domain/ &&
$clean_list eq "inside") {
$parts[1] = "outside";
}
}
> As an efficiency measure, we could also
> pass a "valid token" on the front of @parts so that the do_get function
> wouldn't have to revalidate the form of the command, or just not
> validate the command line in do_get if a pre_command{"get"} existed,
> assuming that the pre-get did the validation for us.
Interesting idea, but I wouldn't trust a "pre_" subroutine to do proper
validation. One of the main reasons for having hooks for "pre_"
routines is to allow local variations to the standard commands.
Therefore, the standard commands are a constant while the "pre_"
commands will have quite a bit of variability. I would expect
the average "pre_" command to be rather "quick and dirty". So I think
the standard command should not trust that the pre_command
validated anything, and should go through the full checks (just
in case a poorly-designed pre_ command changes one wrong value
to a different wrong value).
- Alan
---- ,,,,
Alan Millar amillar@bolis.SF-Bay.org __oo \
System Administrator =___/
Action figures sold separately.
Follow-Ups:
References:
|
|
