On 2012-06-12 04:32, Jeremy Harris wrote:
> In a fit of coding insanity I ran up the following:
>
> + 9. New expansion item ${acl {name}{argument}} to call an ACL. The
> argument can
> + be accessed by the ACL in $address_data. The expansion result is
> set by
> + a "message =" modifier and an "accept" return from the ACL.
>
> Is there any value in this going forward?
I like this idea. We already have "acl = some_other_acl" syntax which
allows calling other ACLs as if they were subroutines/functions. Passing
arguments to and return values from these subroutines currently requires
using individually named global $acl_* variables, which is ugly.
The proposed interface would allow making generic ACL subroutines
without needing to pass around their arguments in global variables.
Phil's comment is valid: there is no point in overloading an existing
variable to be used for the subroutine argument(s).
This makes me think: perhaps the facility could also allow multiple
arguments, as in ${acl {name}{argument1}{argument2}{argument3}}.
The subroutine/sub-acl could receive these arguments in $arg1, $arg2,...
variables and also supply $argn which gives the number of supplied
arguments?
--
Janne Snabb / EPIPE Communications
snabb@??? -
http://epipe.com/
