> > 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.
>
> Nope, just set it up so that the reurn is:
>
> ($error, @parts) = pre_command{$key}...;
>
> I try to stay away from globbed forms as much as possible especially
> where perl novices are likely to be writing pre/post commands.
Good point
> Probably a versioned valid request would be needed. E.G. lets call the
> current "get <list> <file>" majordomo command line version 1, then the
> pre command that parses this should put "valid_v1" onto the @parts
> array. Any replacement version of get (e.g. "get <list> <passwd>
> <file>" would recognize the bogus valid token, and parse the @parts
> array anyway. (Not quite sure how that would work with cascaded pre_
> functions).
>
> Also as I have found before, if you don't give a developer a mechanissm to
> do things like bypass redundent checks, one of 2 things happens:
>
> 1) They don't bypass the checks making things run less efficiently
I agree that developers may do that. But I don't imagine it is likely
with Majordomo because (1) the validations on existing commands take
less than a few seconds and (2) even if they took longer, this is
not an interactive program where the user perceives any semblance
of response time to that level.
> One thing I misssed is that there may be a cascade of pre_ commands. I
> can see a pre command from one module that maps mailing list names
> under the control of a set of config file parameters, while another
> maps bare subscribe/unsubscribe requests sent to -request to standard
> subscribe/unsubscribe requests. What I am aiming for is the ability to
> have module developers code to a standard interface so that modules
> can be dropped in and out at will, and should work with any version of
> majordomo provided the follow the spec for a pre/post/do function.
This is getting much more complex. I would imagine using the Perl
package feature to contol this, but I'm not sure how.
> Also, I guess this is a good time to deal with the problem of
> documentation. One problem with Brent's help message is extending it.
> If a new do_command is added, where is the commentary for it in the
> help message? How do we register the comments? How do we display them?
>
> The only problem I see with your auto-discovery ability is that
> somebody can add a majordomo command without documenting it.
True. It needs something.
> I would suggest 3 functions:
>
> add_do(function_name (e.g. do_subscribe), majordomo_command (e.g. add),
> type (admin|user), comments);
> add_pre(function_name (e.g. pre_add), majordomo_command, [location] );
> add_post(function_name (e.g. post_add), majordomo_command, [location] );
Sounds promisings; I'll have to think it through some more.
- Alan
---- ,,,,
Alan Millar amillar@bolis.SF-Bay.org __oo \
System Administrator =___/
I am the great Oz! Pay no attention to that man behind the curtain!
References:
|
|
